Oberon space
General Category => Общий раздел => Тема начата: valexey от Февраль 11, 2012, 08:32:35 am
-
Оригинал где-то там: http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838
Так получилось, что уже не раз люди, ратующие за "анализ сложных задач" и т.п., бросали мне упрёк, что я акцентирую внимание на "всякой ерунде, этого внимания не заслуживающего". На данном форуме это некогда делали и alexus, и Galkov, и другие.
Поскольку непонимание до сих пор имеет место быть... Возникло желание разъяснить данный вопрос.
1) В тех рабочих группах, с которыми мне приходится работать, решаются достаточно сложные и нетиповые задачи. Поэтому глупо меня обвинять в том, что мне нужны "кодеры". Хотя, конечно, на парах я стремлюсь научить всякой "рутине" и только "низкоуровневым" творческим и аналитическим элементам, потому что реально всё остальное у заинтересованной части аудитории потом формирую отдельными проектами, часто связанными с реальными. Посторонние к учебному процессу люди обычно не понимают, что часов всегда дефицит. И банально нет возможности очень далеко залезать, потому что без "фундамента" (банального с точки зрения критиков) их тоже не оставишь.
Хотя, признаю честно, я долго боялся активных форм обучения - и только сейчас, после того, как у нас в институте прошло повышение квалификации с приглашённым педагогом-психологом из Ростова, рискнул работать по активной схеме - с делением на команды, проблемными задачами - и потом только "догоняющей теорией". Пока идёт отлично.
2) Ну а теперь про "рутину".
На мой взгляд, одна из нерешённых проблем в ИТ - внедрение "инженерного подхода" на уровень кодирования. Под этим я понимаю:
- гарантированное получение результата (мы доверяем тому, что написали, даже до тестирования, зная, что оно правильное с точностью до опечаток и глупых ляпов, которые и должно будет "срезать" тестирование);
- снижение многообразия в коде, его "обезличивание" (чтобы два обученных "инженерии кодинга" программиста выдавали практически одинаковый код);
- снижение рисков в "велосипедостроении" (чтобы банальная необходимость написать какой-то поисковый или сортирующий цикл не вела к трудностям, ломанию мозга и повышению плотности ошибок. Как выразился Пётр Алмазов - "я хочу переезжать такие задачи трактором, практически не снижая скорости").
Именно этих качеств я хочу от любого члена своей команды. Чтобы его творческая сила была сконцентрирована как раз на анализе задач и проектировании. А не этой рутине.
Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам. Ошибки и разрушение памяти неизбежно - выстроим аппаратные барьеры, и пусть там компонент чудит как хочет. Надёжность обеспечим уровнем выше, на всём множестве изолированных компонентов.
Кстати, именно по такому принципу разрабатывется - и вполне успешно - софт в РКК "Энергия". В частности, для российского сегмента МКС. Недавно на одном отраслевом мероприятии они подробно рассказывали. Используется C++ и инфраструктура GNU, используются библиотеки типа boost, работает это всё на базе QNX и Винды. "Инженерный подход" имеется на уровне организации системы из изолированных компонентов, которые обмениваются данными по протоколам. Проблема кодинга и языка программирования "изолирована" в этих "резервациях". На вопрос: сравнивали ли С++ и Аду? - отвечали: да, конечно, но где нам брать программистов на Аде? И добавляли: "главное - правильная организация жизненного цикла ПО". И я полностью с ними здесь соглашусь. Но если ряд проблем можно решить ниже, ещё на уровне "программирования в малом", зачем тратить усилия на их парирование на организационном уровне?
Чтобы парировать "любой бред" на уровне модулей, используют модульное тестирование. Нет, я не против его - но я хочу, чтобы на тестирование выходил уже практически правильный модуль. Это позволяет нам иметь хорошее качество БЕЗ модульного тестирования, и просто отличное - если потратить дополнительные усилия на него (в ответственным случаях).
Снижение многообразия кода решено поверхностно - введением code-style, общих соглашений и т.п., направленных на сопровождаемость и отчуждаемость кода. Но в любой своей нетривиальной алгоритмической части код не "обезличен", там возникает кустарное решение, найденное хаотичным поиском конкретного программиста. Как раз несопровождаемое. И никакими инструкциями эту сопровождаемость для "велосипедов" не обеспечишь.
Поэтому паническая их, "велосипедов", боязнь. Потому что при текущем положении дел они, действительно, несут большие риски. Но и подход - использование стандартных библиотек - это, по сути, ещё одна "изоляция" проблемы. Загнали проблему в "резервацию", трясёмся и надеемся, что уж в библиотеке-то за годы вылизывания, тестирования и использования она не возникнет. То, что под "крышкой" библиотеки, забыли, как страшный сон. Только бы опять не писать эти ужасные сложные циклы и потом не искать в них ошибки. Я, опять же, не против библиотек, я против того, что, когда выгодно и удобно написать конкретное решение, народ этого не умеет и панически боится. Конструктор не боится индивидуально для своей конструкции, если это обосновано, спроектировать и обсчитать нестандартную часть. Нестандартную арку. Или нестандартную передачу. Или... Т.е. мы имеем вместо конструкторов только сборщиков.
Тут я замечу важный момент: грамотный конструктор, если ему придётся делать нестандартный элемент конструкции, должен сделать его не "наколеночно", а используя некоторые наработанные методы, "культуру" проектирование таких элементов. Он построит его так, что сомнений в правильном его устройстве не будет ни у кого. Т.е. даже нестандартные элементы делаются в некотором смысле "стандартно". Потому что, я думаю, многообразие полезных небольших элементов систем, в общем-то, исчерпываемо - их достаточно небольшое число классов, и дальше оно всё становится, при правильном подходе, подобным друг другу. Реальная нестандартность на малом уровне - исключение. Например, связанное с оптимизациями и проч.
Вот все эти проблемы я и пытаюсь решить, уча, не "кодингу", а "инженерному подходу в кодинге".
-
Оригинал где-то там: http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838
Возникло желание разъяснить данный вопрос.
На мой взгляд, одна из нерешённых проблем в ИТ - внедрение "инженерного подхода" на уровень кодирования. Под этим я понимаю:
- гарантированное получение результата (мы доверяем тому, что написали, даже до тестирования, зная, что оно правильное с точностью до опечаток и глупых ляпов, которые и должно будет "срезать" тестирование);
- снижение многообразия в коде, его "обезличивание" (чтобы два обученных "инженерии кодинга" программиста выдавали практически одинаковый код);
- снижение рисков в "велосипедостроении" (чтобы банальная необходимость написать какой-то поисковый или сортирующий цикл не вела к трудностям, ломанию мозга и повышению плотности ошибок. Как выразился Пётр Алмазов - "я хочу переезжать такие задачи трактором, практически не снижая скорости").
Именно этих качеств я хочу от любого члена своей команды. Чтобы его творческая сила была сконцентрирована как раз на анализе задач и проектировании. А не этой рутине.
Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам. Ошибки и разрушение памяти неизбежно - выстроим аппаратные барьеры, и пусть там компонент чудит как хочет. Надёжность обеспечим уровнем выше, на всём множестве изолированных компонентов.
Снижение многообразия кода решено поверхностно - введением code-style, общих соглашений и т.п., направленных на сопровождаемость и отчуждаемость кода. Но в любой своей нетривиальной алгоритмической части код не "обезличен", там возникает кустарное решение, найденное хаотичным поиском конкретного программиста. Как раз несопровождаемое. И никакими инструкциями эту сопровождаемость для "велосипедов" не обеспечишь.
Поэтому паническая их, "велосипедов", боязнь. Потому что при текущем положении дел они, действительно, несут большие риски. Но и подход - использование стандартных библиотек - это, по сути, ещё одна "изоляция" проблемы. Загнали проблему в "резервацию", трясёмся и надеемся, что уж в библиотеке-то за годы вылизывания, тестирования и использования она не возникнет. То, что под "крышкой" библиотеки, забыли, как страшный сон. Только бы опять не писать эти ужасные сложные циклы и потом не искать в них ошибки. Я, опять же, не против библиотек, я против того, что, когда выгодно и удобно написать конкретное решение, народ этого не умеет и панически боится. Конструктор не боится индивидуально для своей конструкции, если это обосновано, спроектировать и обсчитать нестандартную часть. Нестандартную арку. Или нестандартную передачу. Или... Т.е. мы имеем вместо конструкторов только сборщиков.
Вот все эти проблемы я и пытаюсь решить, уча, не "кодингу", а "инженерному подходу в кодинге".
(выделено мной)
Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"
-
А борьбой с велосипедостроением всегда занимаются как раз "мейнстримщики", панически боящиеся написания своего сложного кода, вместо применения библиотек, потому что понимают, что он будет содержать море ошибок.
А вот давайте спросим у Vlad'a, почему же он боится написания своего сложного кода? ;-) И боится ли он вообще?
PS. А что такое "свой сложный код"? Ну, со словом "свой" я вроде бы еще как-то могу определиться (хотя и то вот есть контора. тысячи программистов - который код там "свой"? просто в этой конторе когда-либо писанный? или писанный за последний год кем-то в конторе? или соседом писаный?). А вот что такое "сложный"?
-
Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"
Ну, alexus уже не раз обхаивал обычную науку, обычную инженерию... Несистемные мы, с его точки зрения. Частностями занимаемся, через опыт и "набивание шишек". А ему доступно знание "сразу и целиком".
Поэтому я не упрекаю его в том, что он не понимает, что развитие в науке/технике, конечно, многовариантно, но каждый из эффективных вариантов, "путей", как правило, "авторитарен". В том смысле, что не предназначен для бездумного смешивания с другими. Нельзя собрать массу людей и сказать "пусть каждый работает, как хочет, любыми методами" - и получить результат. Если на вершину есть несколько путей, то вам придётся выбрать один, которым будете восходить вы. Почему-то этот простой факт вызывает всегда обвинения в отрицании других путей. "Как? Вы выбрали один путь? Так вы считаете, что все другие неверные? Что мой и его и вот его пути неверные? Вы диктатор и не уважаете нашу свободу".
Нужно понять и принять тот простой факт, что в рамках какого-то выбранного пути приходится часто отрицать смешение с другими путями - не потому, что они неправильные, а потому, что они находятся с другой стороны горы, и у вас не хватит расстояния между ног, чтобы идти ими обоими.
Допустим, я выбираю путь, в котором даже при отсутствии модульного тестирования должна быть возможность получать хороший результат. Т.е. я отказываюсь решать проблему качества ПО только на уровне процессов. С необходимостью после этого я должен принять ряд требований к программистам, к их работе - и к содержанию обучения этих программистов.
-
Чем-то это напоминает речь диктатора... будущего диктатора... С "заботой" о ближних, разумеется... Но это, конечно, домыслы. Вроде как... "Я заставлю вас убить в себе дракона"... (с) к/ф "Убить дракона"
Ну, alexus уже не раз обхаивал обычную науку, обычную инженерию...
Про "обычную науку" - всё правильно, а вот про "инженерию" - это Ваши фантазии...
Несистемные мы, с его точки зрения.
И это Ваши фантазии.
Частностями занимаемся, через опыт и "набивание шишек". А ему доступно знание "сразу и целиком".
И это Ваши фантазии. В частности, я много раз говорил о великой пользе ошибок/шишек. Пусть "сразу и целиком" останется на Вашей совести.
Поэтому я не упрекаю его в том, что он не понимает, что развитие в науке/технике, конечно, многовариантно, но каждый из эффективных вариантов, "путей", как правило, "авторитарен".
Это нечто новенькое... Можно подробнее... Не Вы ли говорили о том, что надо искоренять "велосипедостроение"? Не Ваши ли это слова: "снижение многообразия в коде, его "обезличивание" (чтобы два обученных "инженерии кодинга" программиста выдавали практически одинаковый код)"
Откуда же возьмётся многообразие, если все должны писать одинаково?.. Так, кто не понимает многовариантность развития: Вы или я?.. Почему путь "авторитарен" вообще непонятно.
В том смысле, что не предназначен для бездумного смешивания с другими. Нельзя собрать массу людей и сказать "пусть каждый работает, как хочет, любыми методами" - и получить результат.
То есть, "работать, как хочет" - это Ваш вариант творческого процесса?.. Ну... что можно сказать... оригинально, конечно, и смело... слишком... смело. Было бы лучше сначала подумать, а потом написать, а не наоборот.
Если на вершину есть несколько путей, то вам придётся выбрать один, которым будете восходить вы. Почему-то этот простой факт вызывает всегда обвинения в отрицании других путей.
У меня этот факт ничего подобного не вызывает. Путь каждый выбирает сам, и отрицать наличие других путей - глупо. Но ведь это Вы предлагаете завести правила, по которым все должны жить. Это уже произошло, по факту, на оберонкоре... и это не случайность... Я верю, что и на своих командах Вы отрабатываете те же методы. Ваши призывы к однообразию, часть этого процесса.
Нужно понять и принять тот простой факт, что в рамках какого-то выбранного пути приходится часто отрицать смешение с другими путями - не потому, что они неправильные, а потому, что они находятся с другой стороны горы, и у вас не хватит расстояния между ног, чтобы идти ими обоими.
И на этом основании надо отрицать наличие других путей?.. Мне кажется, что это... глупо.
-
Мне в упор не понять, почему ввести правила на отдельном форуме - это заставить всех и везде.
Можно подумать, кто-то что-то Вам обещал, а потом не оправдал ваших ожиданий?
-
Конструктор не боится индивидуально для своей конструкции, если это обосновано, спроектировать и обсчитать нестандартную часть. Нестандартную арку. Или нестандартную передачу.
Ну, на самом деле боится. Очень боится. И не потому, что в рассчетах своих не уверен, а просто потому, что как только появляется нестандартная деталь, то сразу всплывает масса факторов которые конструктор учесть просто не может, но должен, ибо он принял решение применить нестандартную деталь. Это косяки в производстве, это косяки в эксплуатации. Это внезапное удорожение всей конструкции на порядок. Это провал по срокам из за поставщиков.
Поэтому нужна просто ну очень веская причина, я бы даже сказал, необходимость, чтобы применить нечто нестандартное. Это бывает очень-очень редко. В софтверостроении оно тоже бывает весьма редко, но когда бывает - применяют и делают нестандартное. В том числе и в мейнстриме.
PS. В плане не софтвера, а железок/устройств попытки применить "не стандартное" я вижу своими глазами. Обычно оно режется сразу на уровне идеи, хотя, теоретически, с нестандартной деталью оно было бы лучше. У устройства появились бы например новые свойства выводящие его вперед относительно конкурентов. Только вот это устройство так до производства, и тем более до конечного пользователя, не дошло бы никогда. С нестандартной деталью. Либо дошло бы, но с совершенно не конкурентной ценой.
-
Я понимаю, что Вы имеете в виду.
Но я имею в виду не это.
В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле.
Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. :) Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом.
Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч.
-
Я понимаю, что Вы имеете в виду.
Но я имею в виду не это.
В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле.
Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. :) Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом.
Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч.
Мы сейчас вступаем на скользкую дорожку аналогий софтверной отрасли с физическим миром. Эта дорожка пока еще никого до добра не доводила :-) (см. например битвы вокруг копирайта и прочей коммерции).
Так вот, по моему мнению, алгоритмы обработки данных отлично упаковываемы в библиотеки. Только это будет, если использовать твою аналогию, не библиотека физических объектов, а библиотека чертежей/планов и так далее. Чертежи и планы превращаются в физический объект после, очевидно, сборки. К счастью в софтвере у нас есть неутомимые автоматические строители-собиральщики, так что я не вижу проблемы в обобщении и повторном использовании алгоритмов обработки данных.
-
Откуда же возьмётся многообразие, если все должны писать одинаково?.. Так, кто не понимает многовариантность развития: Вы или я?.. Почему путь "авторитарен" вообще непонятно.
По моему мнению, по мере развития какой-либо области человеческих дел, идёт постоянное продвижение вперёд "фронта интересных вопросов". То, что вчера было в центре внимания и для развития области требовало многовариантности и творческого поиска, сегодня уже целесообразно делать единообразным, оставляя только лучшие и действительно взаимодополняющие варианты. Так всегда происходило. Никому не придёт в голову спорить о начертаниях линий в чертежах.
Т.е. после того, как вопрос изучен со всех сторон, для развития требуется уже не многообразие, а его сокращение. Чтобы силы перебрасывались вперёд, на действительно интересные вещи.
Разумеется, всегда небольшое число исследователей продолжает изучать и старые вопросы. И часто находит новые решения. Но не все топчутся на одном месте и в сотый раз решают уже решённые задачи.
В этом смысле я тоже как раз попадаю под категорию таких исследователей. ИТ-отрасль не решила проблемы уровня "кодинга" (я не люблю это слово, просто dizer мне тут его "повесил" - и я его буду употреблять в нашем разговоре), но просто нашла способы их "изолировать" - парировать проблемы уровнем выше, процессами разработки. Я же как бы зову назад: давайте всё-таки дорешаем... :)
P.S. Не нужно думать, что я тут только этим и занимаюсь, как этими проблемами.
-
Эти задачи сегодня "залечены", фактически, по принципу "изоляции проблем программирования в малом". Этот принцип подобен изоляции процессов в ОС - когда до появления безопасных языков единственным способом получить защищённые друг от друга компоненты было разнесение их по разным адресным пространствам.
К слову, я пока не видел ни одного безопасного языка. То есть для защищенности ВСЕГДА нужно разносить компоненты по разным адресным пространствам. А еще лучше - по разным машинам.
-
"Почему авторитарность".
Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко :)
Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
У сообщества своё понимание "пути к вершине", они и сами им идут, и желающих берут "в поход".
Поскольку люди широких интересов, то интересуются они и вообще сферой боевых искусств. Поэтому на форуме есть разделы, где все желающие могут обсуждать и дзюдо, и айкидо, и каратэ-до. Хозяева форума не прочь послушать и пообщаться и на эти темы.
Проблемы бывают трёх категорий:
1) Поклонники "дворового мордобоя", которых в обществе вокруг очень много, и которые не прочь постоянно похаять боевые искусства, как "бесполезные", "академические", "непрактичные" и проч.
2) Поклонники других направлений боевых искусств, которые считают, что направление хозяев устарело, будет отмирать, и только направления их типа выживут в будущем.
3) Люди, не выделяющие течений, а считающие, что есть "боевое искусство вообще". Когда они видят попытку развить отдельное направление в его чистой форме, они искренне возмущаются "авторитарности" этого направления, его "косности" и нежеланию "заимствовать". "Ну почему бы вам, дзюдоистам, не прикрутить вот эту замечательную штуку из бокса?"
И как только представители всех 3 категорий начинают создавать препятствия конструктивной работе сообщества и его форума - путём провоцирования бессмысленных споров (в рамках развития конкретного чистого течения) и т.п. - вот тут и начинаются конфликты.
Первые, правда, быстро бросают ходить - они считают сообщество "чудаками".
Вторых было не так много - и как-то успокоилось.
А вот с третьими - волна за волной.
-
"Почему авторитарность".
Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко :)
Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
Забавно что в качестве иллюстрации выбраны именно боевые искусства :-)
Замечу, что боевые они нынче именно что искусства. В том плане, что наличие ножа у обычного человека резко повышает его "уровень", чуть ли не до черного пояса. Интересующиеся могут посмотреть тут и вокруг: http://thesz.livejournal.com/1172418.html?thread=9887682#t9887682
То есть в обычной жизни если нам не шашечки, а ехать, лучше таки нож. А еще лучше пистолет. При этом боевые искусства конечно же ценны. Ценны как красивая традиция, как навыки и знания накопленные веками, как определенная культура. Но практическая ценность от них бывает редко-редко и в очень специфических ситуациях.
Так вот - в плане программирования нам нужно что - шашечки, или ехать? Красивая традиция, древняя культура, или же практическая ценность?
-
Рассмотрите мой пример применительно к разным течениям рукопашного боя спецслужб, например. Там тоже нет "единого рукопашного боя". Есть, например, стиль Кадочникова. Есть другое.. и т.п.
-
"Почему авторитарность".
Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко :)
Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
У сообщества своё понимание "пути к вершине", они и сами им идут, и желающих берут "в поход".
Поскольку люди широких интересов, то интересуются они и вообще сферой боевых искусств. Поэтому на форуме есть разделы, где все желающие могут обсуждать и дзюдо, и айкидо, и каратэ-до. Хозяева форума не прочь послушать и пообщаться и на эти темы.
Проблемы бывают трёх категорий:
1) Поклонники "дворового мордобоя", которых в обществе вокруг очень много, и которые не прочь постоянно похаять боевые искусства, как "бесполезные", "академические", "непрактичные" и проч.
2) Поклонники других направлений боевых искусств, которые считают, что направление хозяев устарело, будет отмирать, и только направления их типа выживут в будущем.
3) Люди, не выделяющие течений, а считающие, что есть "боевое искусство вообще". Когда они видят попытку развить отдельное направление в его чистой форме, они искренне возмущаются "авторитарности" этого направления, его "косности" и нежеланию "заимствовать". "Ну почему бы вам, дзюдоистам, не прикрутить вот эту замечательную штуку из бокса?"
И как только представители всех 3 категорий начинают создавать препятствия конструктивной работе сообщества и его форума - путём провоцирования бессмысленных споров (в рамках развития конкретного чистого течения) и т.п. - вот тут и начинаются конфликты.
Первые, правда, быстро бросают ходить - они считают сообщество "чудаками".
Вторых было не так много - и как-то успокоилось.
А вот с третьими - волна за волной.
Ого,какие хорошие ХОЗЯЕВА :) :) :) :) и слушают и общаются.... а остальные да, плохие - но ладно, за что же вы тогда "своих" то "мочите" - за то, что им стало тесно работать в вашем "стиле" делать Q при упоминание Вирта, "страшно выпучив глаза" каждое утро орать принцип Калашникова -а пытаются хоть как -то связать коровник с реальностью?-любители "определенного" стиля
-
Рассмотрите мой пример применительно к разным течениям рукопашного боя спецслужб, например. Там тоже нет "единого рукопашного боя". Есть, например, стиль Кадочникова. Есть другое.. и т.п.
Но прям таки к "искусствам" это постольку поскольку. Без приплетения религии и особой философии. Цель проста - наиболее эффективно вырубить противника используя все, что под руку попадется.
Поэтому не надо идти к некому абстрактному просветвлению, нужно стремиться к эффективности решения возникающих задач в реальном мире.
PS. И таки да, погрузившись в волшебный мир микроконтроллеров я вижу, что за последние лет 20 особого прогресса в софтверостроении по сути нет. Микроконтроллеры, в отличае от CPU десктопов и серверов, развиваются в другом направлении - при сохранении текущей производительности каждая следующая версия микроконтроллера имеет меньший размер, потребление и больше интегрированных контроллеров в чип (например I2C). Так вот - инструментарий для написания софта, библиотеки и подходы там где-то на уровне 80-90 годов как были, так и остались. Ничего не меняется. То есть, вот конкретно тут есть куда расти отрасли. Причем экстенсивно тут не выйдет. Тут думать нужно.
-
Поэтому не надо идти к некому абстрактному просветвлению, нужно стремиться к эффективности решения возникающих задач в реальном мире.
:) Эк до чего договорились -! Да нет, можно идти (делать сознательные шаги) к нему, либо нет. Идти к нему , можно и стремясь " к эффективности решения возникающих задач в реальном мире" так и многими другими способами. Но ради интереса я попробовал орать по утру принцип Калашникова (был с похмелья) - светвлиться не стал, может все дело в особой технике "выпучивания глаз" раскрываемой в "закрытой" ветке коровника (это что бы светвлящихся много не разводилось - а то ведь и "темноты" не будет).
-
Мне в упор не понять, почему ввести правила на отдельном форуме - это заставить всех и везде.
Можно подумать, кто-то что-то Вам обещал, а потом не оправдал ваших ожиданий?
Вы правы... перед тем, как придти на оберонкоре (равно, как и на данный форум), я внимательно прочитал правила. Эти правила обещали мне... На поверку, всё оказалось иначе, оказывается есть люди, которые обязаны соблюдать данные правила, а есть те, кому на них наплевать. И, как ни странно, первые всегда виноваты, а вторые всегда правы. Типичный пример, когда у второй стороны нет аргументов, она "отвечает" оппонентам... с помощью действий модератора.
Если Вы позволите, то я Вам напомню историю месячной давности.
- Вы начали тему, где стали "петь дифирамбы" "циклу Дейкстры" (ЦД), и привели пример, где якобы использование ЦД даёт более эффективную реализацию;
- На это С.Ю. Губанов привёл решение, которое показывает, что возможно решение Вашей задачи без ЦД в несколько раз быстрее, чем приведённое Вами;
- Я выразил восхищение быстротой и качеством решения С.Ю. Губанова и предложил вариант его развития;
- Вы обрушились на меня с претензиями, якобы моё предложение не относится к Вашей постановке задачи;
- Я Вам на это сказал, что Ваше решение я даже не рассматривал, а комментировал решение С.Ю. Губанова;
- Модератор секвестировал мой ответ Вам.
Может быть хотя бы Вы ответите, какие правила я нарушил? Да, я считал и продолжаю считать, что ЦД затрудняет понимание логики программы, и от него надо стараться отказываться при появлении любой внятной альтернативы. Пример с решением, предоставленным С.Ю. Губановым, замечательное тому подтверждение. У Вас не было и сейчас нет весомых аргументов, опровергающих данное положение. В результате были применены административные меры, так как моя точка зрения стала нарушением правил вашего форума? К Вашей совести я не обращаюсь... просто повторю... тьфу и на вас всех...
-
А вот давайте спросим у Vlad'a, почему же он боится написания своего сложного кода? ;-) И боится ли он вообще?
Писать сложный код намного проще, чем простой - думать меньше надо :) Не пишу я его потому что это дорого:
- его сложнее тестировать
- его сложнее понимать и менять потом (мое любимое сопровождение, да)
- его надо документировать
Конечно в момент написания можно и не думать об этих пунктах - тогда вообще халява :)
Последние несколько дней решал такую задачу:
Есть интеркативная форма. Есть вычисления на сервере. Форма отображается результаты вычислений (результаты совершенно разного вида, заранее неизвестного). Нужно, собственно, обеспечить интеркативность - пока там чего-то вычисляется, форма должна оставаться интерактивной (до какой-то степени). Короче, ближайшая аналогия - это веб браузер, который отображает страницу по мере ее загрузки.
Ну понятно, что появляется многопоточность. Тема сама по себе сложная, кроме того я с ней редко сталкиваюсь в повседневной практике, поэтому было над чем поразмыслить. Из дополнительных особенностей - результаты уже запущенных вычислений надо уметь игнорировать (форма перешла в другое состояние или просто была перезагружена/закрыта). Кроме того, надо уметь определить, что какие-то вычисления еще не завершились и подождать их завершения (чтобы форма могла перейти в следующее состояние).
В результате нескольких итераций родился один компонент с интерфейсом из нескольких методов (можете тоже поразмыслить и пределожить возможные варианты - посмотреть насколько мысли сходятся). Из ~5 комментариев типа "здесь мы лочим мьютекс потому что... а здесь не лочим потому что..." остался один - потому что я смог упростить код так, что одни моменты стали очевиднее, а другие моменты "покрыть" тестами (да, юнит тестик тоже появился вместе с компонентиком). Оставшийся один комментарий - действительно тонкий момент, который я не смог покрыть тестом (высокая "конкурентность" между двумя действиями, возможная проблема не репродьюсится даже на сотне потоков и множестве итераций). Возможно при большем опыте я бы смог выразить этот момент в коде, но пока остается только комментарий :)
Сам компонент не имеет зависимостей от других компонентов (формы). Точнее использует только один абстрактный коллбэк (который в итоге цепляется к форме, а в юниттесте легко подставляется заглушка).
Понятно, что для таких задач никогда не будет ничего готового в стандартной библиотеке. Ну разве что там будет компонент "веб браузер" ;) С другой стороны, я не хочу каждый раз начинать с нуля: я хочу иметь в библиотеке потоки, примитивы синхронизации и даже "очередь". Иначе 90% времени я буду тратить на совершенно неинтересную фигню типа особенностей condition variables на конкретной платформе (да, код писан/тестирован был на винде, но сразу заработал на маке).
Да, каким боком мне помогли бы здесь заинтриговавшие меня карты памяти - пока не представляю. Подозреваю, что это просто еще более высокий уровень системы.
-
Последние несколько дней решал такую задачу:
А какой язык использовался?
-
А какой язык использовался?
C++ и библиотека boost.
Есть у кого в ББ готовые наработки, чтобы такое решить без отвлечения на частности (прежде всего речь о наработках в области межпроцессного взаимодействия разных экземпляров ББ)? Т.е. чтоб "IMPORT IPC;" и вперед. И если есть, то как это примерно выглядит (архитектурно)?
-
А какой язык использовался?
C++ и библиотека boost.
Есть у кого в ББ готовые наработки, чтобы такое решить без отвлечения на частности (прежде всего речь о наработках в области межпроцессного взаимодействия разных экземпляров ББ)? Т.е. чтоб "IMPORT IPC;" и вперед. И если есть, то как это примерно выглядит (архитектурно)?
Погоди, а как в ББ архитектурно будет выглядеть многопоточность вообще? Или у тебя считалось в другом процессе а не потоке? По моему, данная задача может быть решена не одним ББ а ансамблем из нескольких ББ + неблокирующие операции для коммуникаций.
-
Погоди, а как в ББ архитектурно будет выглядеть многопоточность вообще? Или у тебя считалось в другом процессе а не потоке? По моему, данная задача может быть решена не одним ББ а ансамблем из нескольких ББ + неблокирующие операции для коммуникаций.
Да, я имел ввиду вариант нескольких ББ.
-
Может быть хотя бы Вы ответите, какие правила я нарушил? Да, я считал и продолжаю считать, что ЦД затрудняет понимание логики программы, и от него надо стараться отказываться при появлении любой внятной альтернативы. Пример с решением, предоставленным С.Ю. Губановым, замечательное тому подтверждение. У Вас не было и сейчас нет весомых аргументов, опровергающих данное положение. В результате были применены административные меры, так как моя точка зрения стала нарушением правил вашего форума? К Вашей совести я не обращаюсь... просто повторю... тьфу и на вас всех...
Может быть хотя бы Вы ответите, какие правила я нарушил? Да, я считал и продолжаю считать, что ЦД затрудняет понимание логики программы, и от него надо стараться отказываться при появлении любой внятной альтернативы. Пример с решением, предоставленным С.Ю. Губановым, замечательное тому подтверждение. У Вас не было и сейчас нет весомых аргументов, опровергающих данное положение. В результате были применены административные меры, так как моя точка зрения стала нарушением правил вашего форума? К Вашей совести я не обращаюсь... просто повторю... тьфу и на вас всех...
Во-первых, по ЦД я ничего не имею против Ваших с Губановым бесед. Они никак не противоречили моему сообщению. В том числе о том, что был оставлен ЦД "за явным преимуществом" (разумеется, понятности, а не эффективности, потому что ниже в ветке я изложил свой взгляд на эффективность, в рамках которого множитель 1,5-2 для конкретного куска кода меня, по умолчанию, не волнует, в отличие от того же удачно организованного управления памятью, которое даёт реально гораздо больший эффект для многих задач).
Понятность, про которую я говорю, была оценена двумя людьми (коллегой-студентом и мной; при этом я отказался от своего варианта с вложенными циклами, хотя первоначально не доверял ЦД). Возможно, это субъективная понятность, для людей с определённым "разворотом мозгов" (мы привыкли к инвариантам циклов, с одной стороны, и к "автоматному программированию", с другой). Но это никак не позволяет Вам "гнуть пальцы", что вы нам "что-то там показали". Я отказался от тех вариантов, которые ниже Вы предложили с Губановым, ещё до того, как заводил тему на форуме. За идею Губанова сравнивать сначала с первой буквой, а потом во вложенной процедуре, я его поблагодарил и публично на форуме, и в ЛС, потому что идея для меня показалась свежей и эффектной.
Ну а по поводу того, что Вас кто-то обидел административными мерами - какая-то полная ерунда. Тему поделили на две в силу того, что в ней пошло обсуждение вопросов эффективности, а не вопросов понятности и лёгкости составления циклов тем или иным способом. Поделили вообще без моего участия. Такое деление у нас выполнялось неоднократно - потому что при любом обсуждении подобных тем всегда кто-то поднимает тему "выжимания максимума", и эту тему у нас принято считать побочной. И отделять обычно из образовательных форумов в "Другие вопросы программирования".
И нарушение правил в ветке было не в плане какой-то "злостности" или "политики", а в том смысле, что ветка содержала другую тему. Которая и была отделена.
На Вас вообще никто не держал никакого "камня за пазухой". Губанов и Info21 начали очередную ссору, которые у них постоянно. Поэтому ветка стала "конфликтной". Вы там ни с какого боку не в "эпицентре". Единственное, что в горячке их разборки Вам никто ничего не объяснял, что могло вызвать ощущение, что "разборки" как-то направлены и против Вас.
Поэтому я крайне удивлён вашими словами здесь. Много нового узнал про Вас. И не только я, кажется...
-
На Вас вообще никто не держал никакого "камня за пазухой". Губанов и Info21 начали очередную ссору, которые у них постоянно. Поэтому ветка стала "конфликтной". Вы там ни с какого боку не в "эпицентре". Единственное, что в горячке их разборки Вам никто ничего не объяснял, что могло вызвать ощущение, что "разборки" как-то направлены и против Вас.
Поэтому я крайне удивлён вашими словами здесь. Много нового узнал про Вас. И не только я, кажется...
Объясните конкретно, почему было секвестировано моё сообщение Термингалеевым?..
Что касается "узнавания нового", то я (и не только я) узнал про вашу команду ничуть не меньше... этого хватило на то, чтобы прекратить общаться с вами всеми. Возможно, вы неплохие специалисты, но... порядочности вам не хватает. И проблема в том, что стать неплохим специалистом можно, а вот...
-
Может быть хотя бы Вы ответите, какие правила я нарушил? Да, я считал и продолжаю считать, что ЦД затрудняет понимание логики программы, и от него надо стараться отказываться при появлении любой внятной альтернативы. Пример с решением, предоставленным С.Ю. Губановым, замечательное тому подтверждение. У Вас не было и сейчас нет весомых аргументов, опровергающих данное положение. В результате были применены административные меры, так как моя точка зрения стала нарушением правил вашего форума? К Вашей совести я не обращаюсь... просто повторю... тьфу и на вас всех...
Во-первых, по ЦД я ничего не имею против Ваших с Губановым бесед. Они никак не противоречили моему сообщению. В том числе о том, что был оставлен ЦД "за явным преимуществом" (разумеется, понятности, а не эффективности, потому что ниже в ветке я изложил свой взгляд на эффективность, в рамках которого множитель 1,5-2 для конкретного куска кода меня, по умолчанию, не волнует, в отличие от того же удачно организованного управления памятью, которое даёт реально гораздо больший эффект для многих задач).
Так вот ты какая, инженерия кодинга
-
Объясните конкретно, почему было секвестировано моё сообщение Термингалеевым?..
Напомните детали. Я вообще не обращал на ту ветку внимания. Что помню, я Вам написал выше - пошло обсуждение эффективности - его отделили.
-
Объясните конкретно, почему было секвестировано моё сообщение Термингалеевым?..
Напомните детали. Я вообще не обращал на ту ветку внимания. Что помню, я Вам написал выше - пошло обсуждение эффективности - его отделили.
- Вы начали тему, где стали "петь дифирамбы" "циклу Дейкстры" (ЦД), и привели пример, где якобы использование ЦД даёт более эффективную реализацию;
- На это С.Ю. Губанов привёл решение, которое показывает, что возможно решение Вашей задачи без ЦД в несколько раз быстрее, чем приведённое Вами;
- Я выразил восхищение быстротой и качеством решения С.Ю. Губанова и предложил вариант его развития;
- Вы обрушились на меня с претензиями, якобы моё предложение не относится к Вашей постановке задачи;
- Я Вам на это сказал, что Ваше решение я даже не рассматривал, а комментировал решение С.Ю. Губанова;
- Модератор секвестировал мой ответ Вам.
Это было описано несколькими сообщениями выше. Остальные детали можете искать на своём форуме... в этом бедламе, я вряд ли смогу что-то найти...
-
Я это прочитал.
И пояснил, почему ветка была разделена.
(ни с какими претензиями личными я вообще не обрушивался, а сказал, что обсуждение идёт не в ту сторону, на которую была открыта тема).
Посему можете не цитировать Ваш "список событий" повторно, я считаю, что исчерпывающе объяснил всё, что его касается.
Но я не помню, о каком сообщении идёт речь: "Объясните конкретно, почему было секвестировано моё сообщение Термингалеевым?.." - и по этому пункту ничего предполагать не могу. (и то, предполагать - потому что я - не администрация форума).
-
Я это прочитал.
И пояснил, почему ветка была разделена.
А я об этом не спрашивал...
(ни с какими претензиями личными я вообще не обрушивался, а сказал, что обсуждение идёт не в ту сторону, на которую была открыта тема).
Посему можете не цитировать Ваш "список событий" повторно, я считаю, что исчерпывающе объяснил всё, что его касается.
Тему начали Вы... В заголовке темы было о "Цикле Дейкстры"... никуда в сторону от обсуждения ЦД мы не отклонялись. Сергей Губанов привёл альтернативу, я его поддержал. Флейм начался в параллельной ветке, я в нём не участвовал. Всё.
Но я не помню, о каком сообщении идёт речь: "Объясните конкретно, почему было секвестировано моё сообщение Термингалеевым?.." - и по этому пункту ничего предполагать не могу. (и то, предполагать - потому что я - не администрация форума).
Хорошо... напомню... (http://forum.oberoncore.ru/viewtopic.php?p=69781#p69781)
Илья, я понимаю, что очень неприятно, когда тычут... лицом в своё же... Мне это ничуть не приятнее, чем Вам... делаю я это только для того, чтобы Вы могли посмотреть на себя же... другими глазами... Теплится у меня надежда, что может быть ещё не поздно... хотя понимаю, что вряд ли...
-
Илья, что скажишь по поводу вот этого:
А какой язык использовался?
C++ и библиотека boost.
Есть у кого в ББ готовые наработки, чтобы такое решить без отвлечения на частности (прежде всего речь о наработках в области межпроцессного взаимодействия разных экземпляров ББ)? Т.е. чтоб "IMPORT IPC;" и вперед. И если есть, то как это примерно выглядит (архитектурно)?
Как такое в ББ решается сейчас (и решается ли вообще?).
-
Мне не неприятно, мне всё равно то, о чём мы тут с Вами говорим. У меня нет такой трепетности к сетевому общению, как у многих. И какое там обрывочное впечатление кто-то себе достраивает по репликам на фоурмах - тоже.
Теперь о деле. Я не помню, что было в том сообщении. Могу предположить, что там был какой-то ответ на моё? Тогда его удалили вместе с моим сообщением раньше, чем я прочитал. Я редко бываю на форумах в "реальном времени".
Кроме того, вероятно, то, что было сочтено администрацией "пикировкой", начал я, а не Вы. Таким образом, именно моё нарушения стало причиной того, что потом вырезали что-то из Вашего сообщения (как упоминание моего удалённого). Мои сообщения тоже нередко модерируют, потому что водится за мной грешок - сначала написать, а потом уже подумать.
Т.е. в данной ситуации Вы, могу предполагать, ни в чём не нарушили правила. А нарушил я (или кому была адресована удалённая часть вашего сообщения?).
-
Илья, что скажишь по поводу вот этого:
Как такое в ББ решается сейчас (и решается ли вообще?).
Мы пробовали грузить несколько ББ в одно адресное пространство и взаимодействовать между ними через спец. объекты, типа Files.File в памяти. Т.е. эти объекты инкапсулируют разделяемую память, работа с которой ведётся сторонами через ридеры-врайтеры.
Понимание есть, планы есть; реально проекты пока в однопоточном режиме, т.к. в коммерческих задачах хватало; а на "перспективу" не хватает времени...
-
Илья, что скажишь по поводу вот этого:
Как такое в ББ решается сейчас (и решается ли вообще?).
Мы пробовали грузить несколько ББ в одно адресное пространство и взаимодействовать между ними через спец. объекты, типа Files.File в памяти. Т.е. эти объекты инкапсулируют разделяемую память, работа с которой ведётся сторонами через ридеры-врайтеры.
Понимание есть, планы есть; реально проекты пока в однопоточном режиме, т.к. в коммерческих задачах хватало; а на "перспективу" не хватает времени...
А в принципе как задача подобная той что у Влада решается (http://oberspace.dyndns.org/index.php/topic,184.msg3217.html#msg3217)? В рамках одного ББ, или же в рамках ансамбля ББ (каждый в своем адресном пространстве, то есть по процессу на брата)?
-
Т.е. в данной ситуации Вы, могу предполагать, ни в чём не нарушили правила. А нарушил я (или кому была адресована удалённая часть вашего сообщения?).
... а может и правда не поздно?..
Удивительно, что подобие организованных структур встречается в хаосе... правда, оно очень недолговечно и рассыпается так же быстро, как и образуется...
-
Мы пробовали грузить несколько ББ в одно адресное пространство и взаимодействовать между ними через спец. объекты, типа Files.File в памяти. Т.е. эти объекты инкапсулируют разделяемую память, работа с которой ведётся сторонами через ридеры-врайтеры.
Понимание есть, планы есть; реально проекты пока в однопоточном режиме, т.к. в коммерческих задачах хватало; а на "перспективу" не хватает времени...
Попытаюсь конкретизировать. Если мне скажут, что мне больше недоступна многопоточность, то применительно к запуску копий у меня сразу возникнут следующие вопросы:
1. Как два и более экземпляров будут уживаться одновременно:
- как они делят логгинг
- как они делят взаимодействие с ОС (регистрируются себя на каких-то портах или как теперь будут открываться файлы .odc).
2. Как будет выглядеть неблокирующее взаимодействие. Т.е., в какой момент будет делаться push и в какой момент будет делаться poll/pull.
3. Насколько прозрачно это будет для приложения в целом. Т.е. что можно и что нельзя делать при написании совершенно других частей приложения, не имеющих прямого отношения к такой реализации "многопоточности". Например, если я добавляю фичу, показывающую иконку в трее - не должно возникнуть ситуации, что в какой-то момент в трэе стало показываться 10 иконок.
P.S. Сама "связь" с точки зрения реализации IPC (pipes, shared memory, mutexes), включая сериализацию - не сильно интересно, легко представить и про "типизированные файлы" в обероне я уже читал.
-
Мы пробовали грузить несколько ББ в одно адресное пространство и взаимодействовать между ними через спец. объекты, типа Files.File в памяти. Т.е. эти объекты инкапсулируют разделяемую память, работа с которой ведётся сторонами через ридеры-врайтеры.
Понимание есть, планы есть; реально проекты пока в однопоточном режиме, т.к. в коммерческих задачах хватало; а на "перспективу" не хватает времени...
Попытаюсь конкретизировать. Если мне скажут, что мне больше недоступна многопоточность, то применительно к запуску копий у меня сразу возникнут следующие вопросы:
1. Как два и более экземпляров будут уживаться одновременно:
- как они делят логгинг
- как они делят взаимодействие с ОС (регистрируются себя на каких-то портах или как теперь будут открываться файлы .odc).
2. Как будет выглядеть неблокирующее взаимодействие. Т.е., в какой момент будет делаться push и в какой момент будет делаться poll/pull.
3. Насколько прозрачно это будет для приложения в целом. Т.е. что можно и что нельзя делать при написании совершенно других частей приложения, не имеющих прямого отношения к такой реализации "многопоточности". Например, если я добавляю фичу, показывающую иконку в трее - не должно возникнуть ситуации, что в какой-то момент в трэе стало показываться 10 иконок.
P.S. Сама "связь" с точки зрения реализации IPC (pipes, shared memory, mutexes), включая сериализацию - не сильно интересно, легко представить и про "типизированные файлы" в обероне я уже читал.
Вот к примеру браузер... На каждое окно по процессу (почти)... и логи делят, и трей... и из оконного интерфейса не конфликтуют, но это было изначально заложено/спроектировано. А прикручивать "по ходу дела"... одна головная боль. Дело даже не в том, как разделить ресурсы, нужен качественный арбитраж... над-система... а её из частных задач не выведешь, надо сесть и специально спроектировать.
-
Вот к примеру браузер... На каждое окно по процессу (почти)... и логи делят, и трей... и из оконного интерфейса не конфликтуют, но это было изначально заложено/спроектировано. А прикручивать "по ходу дела"... одна головная боль. Дело даже не в том, как разделить ресурсы, нужен качественный арбитраж... над-система... а её из частных задач не выведешь, надо сесть и специально спроектировать.
Угу. Вот у меня точно такое же ощущение - нужно садиться и специально проектировать. Иначе будет лажа, которую постоянно залатывать надо.
-
Попытаюсь конкретизировать. Если мне скажут, что мне больше недоступна многопоточность, то применительно к запуску копий у меня сразу возникнут следующие вопросы:
Нет, многопоточности нет в каждой отдельно взятой копии ББ. А так - каждая копия запускается со своим потоком.
Получаются изолированные объектные пространства (и сборки мусора в них), но общее адресное, что позволяет разделять двоичную память.
Как в MS Singularity - "software isolated processes".