Oberon space

"Почему авторитарность".

Расскажу надуманную историю. Надеюсь, знатокам Востока будет близко

Существует сообщество и форум деятелей какого-нибудь направления боевых искусств. Например, "за-ши-бу" (С) "3 богатыря".
У сообщества своё понимание "пути к вершине", они и сами им идут, и желающих берут "в поход".
Поскольку люди широких интересов, то интересуются они и вообще сферой боевых искусств. Поэтому на форуме есть разделы, где все желающие могут обсуждать и дзюдо, и айкидо, и каратэ-до. Хозяева форума не прочь послушать и пообщаться и на эти темы.
Проблемы бывают трёх категорий:
1) Поклонники "дворового мордобоя", которых в обществе вокруг очень много, и которые не прочь постоянно похаять боевые искусства, как "бесполезные", "академические", "непрактичные" и проч.
2) Поклонники других направлений боевых искусств, которые считают, что направление хозяев устарело, будет отмирать, и только направления их типа выживут в будущем.
3) Люди, не выделяющие течений, а считающие, что есть "боевое искусство вообще". Когда они видят попытку развить отдельное направление в его чистой форме, они искренне возмущаются "авторитарности" этого направления, его "косности" и нежеланию "заимствовать". "Ну почему бы вам, дзюдоистам, не прикрутить вот эту замечательную штуку из бокса?"

И как только представители всех 3 категорий начинают создавать препятствия конструктивной работе сообщества и его форума - путём провоцирования бессмысленных споров (в рамках развития конкретного чистого течения) и т.п. - вот тут и начинаются конфликты.
Первые, правда, быстро бросают ходить - они считают сообщество "чудаками".
Вторых было не так много - и как-то успокоилось.
А вот с третьими - волна за волной.

Я понимаю, что Вы имеете в виду.
Но я имею в виду не это.
В инженерии есть составляющие, которые нельзя "упаковать" в повторно используемый компонент. Вы не можете "упаковать" и повторно использовать как физический модуль, например, разводку электросети в автомобиле.
Вы не можете использовать повторно через import и call общую архитектуру здания. ПОтому что Вам придётся import здание. Т.е. для таких элементов повторное использование возможно только на ментальном уровне, но не на уровне физическом или САПР-овом.
Я отношу к таким же "неупаковываемым" вещам алгоритмы обработки данных. Которые народ пытается засунуть в библиотеки. Ценой дикого усложнения инструментов - поддержки супер-обобщёнки и проч.

Ваша проблема, IMHO, что Вы всё постоянно сваливаете в одну кучу (кодирование, проектирование и моделирование, в частности)

Нет, я просто пытаюсь сначала навести порядок в кодировании, а потом над надёжным процессом кодирования надстраивать всё остальное.

Это как если в строительстве какая-нибудь исследовательская группа на время(!) пренебрегает всем, кроме изучения и внедрения новых конструкционных материалов. А затем свойства этих новых материалов должны позволить значительно изменить проектирование зданий, ввиду, например, возможности делать огромные конструкции без опор... Надеюсь, аналогия понятна?

Ещё можно сказать так, что я мечтаю достичь целей, скажем, 4GL-подходов, совместив 3GL-инструмент с соответствующими методами работы на нём. Т.е. в 4GL: описали высокоуровнево решение задачи - оно работает. Я бы хотел: придумали высокоуровнево решение задачи, без усилий и вариаций закодировали его на 3GL.
4GL имеет недостатком необходимость особого инструмента под каждую сферу применения.
3GL + методика работы с ним этого недостатка лишены.

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

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

Какая-то идиосинкразия на "режимность" у образованного народонаселения.
Тыкают в ужасе пальцем и кричат на любое вмешательство в "свободу слова".

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

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

Я прошу прощения, что дал ошибочную ссылку.
Вот эта работает:
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3838

Домыслы советую оставить при себе.

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

http://forum.oberoncore.ru/viewtopic.php?f=86&t=3837

Мой опыт говорит о следующем - самое сложное, умение абстрагировать задачу и формулировать ее в терминах  моделей информатики и окружения (операционной системы),  далее идет -построение алгоритмического решения в терминах использованных моделей. А отображение  алгоритма на конкретный ЯП как правило вносит малый вклад в сложность - ее можно понизить взяв ЯП который описывает наиболее просто данные системы (система лежит в области эффективного использования языка), либо взять простой язык (типа ОБЕРОНА) - но в последнем случае можно напороться на сложности связанные с  большим обьемом кода, реализующего интересующий нас алгоритм ..

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