Про ёжика в тумане, зазнайство, языки программирования и вериги

[vit_r]

Давным-давно написал текст про драконов. Много кто его читал, мало кто понял. Но тут уж я сам виноват. Интегральные вещи очень сложно объяснить представителям западной культуры. Потому как все упирают на анализ и практически никто не владеет синтезом.

Если говорить грубо и просто, краткая выжимка из всех этих попыток такая.

The Software Dragons are heavily connected networks of problems.

They are called Dragons because they cannot be fought with convenient methods. All attempts to solve small problems separately fail because of unintended consequences. All attempts to solve or even to understand the system as whole fail because of the complexity of interdependencies.

You cannot win against them but you can follow 3 rules.

1. Do not ignore Dragons.
2. Do not feed them.
3. And kill them when they are still small.

Текст, конечно, надо переписывать. Но у меня на очереди ещё дофига всего, что надо...

А вспомнил я про эту тему потому, что ailev собирается создавать драконью ферму.

Идея глобальная и благая (Да, направление движения как раз туда).

Подробно мои претензии можно посмотреть по ссылке. Если кратко, то:

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


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


3. Квалифицированных кадров не хватает. Всегда.
   
   А это значит, что всякими модными вещами будут заниматься те, кто бесполезен.
   
   Нет, во время этапа proof of concept на новой технологии могут сидеть гении, практики и высокооплачивыемые спецы. Но как только оно пойдёт в массы, все чудесные базовые вещи, на которых будут основываться мощные системы и умные процессы попадут в руки практикантов, дураков или, ещё хуже, бангалорского оффшора.
   
   (И там загнутся)
   
   


4. Критерий правильной системы один: она экономит время. Причём, не кому-то там дальше по цепочке, а именно тому конкретному человеку, который будет тыкать кнопочки.
   
   Менеджерам можно пообещать экономию времени, экономию бюджета или активацию скрытых резервов. Они ведутся на красивые слова и необоснованную рекламу. Но, если прямым участникам процесса это будет создавать лишнюю работу, всё это выльется в банальный саботаж.
   
   Теоретически бывает по-другому. Практически каждый раз я вижу одно и то же: «Мы готовы это делать, но как-нибудь потом. Сейчас у нас завал с нашей непосредственной работой.»
   
   


5. Любое объединение и нововведение не висит в пустоте, а требует для ногмальной работы объединения с огромными массивами информации, заполненными по старым технологиям. Как правило, это нереально, потому что надо всё переводить в новый язык, новую парадигму или новый формат. На это нет ресурсов и денег. Обычно это ещё и пытаются провернуть дилетанты, выбирая самые дикие способы.
   
   


6. Специалист - это человек, знающий и понимающий несколько смежных миров. И не теоретически, а имеющий много лет реального опыта.
   
   Только такие специалисты-универсалы способны осуществлять контакт между узкими специалистами. Попытка это сделать программами провалится.
   
   Потому что ни одна программа не может вытянуть культуру и контекст.
   
   Студенты и аспиранты, выучившие «Самую Правильную Методику», тоже не могут. Слишком много есть вещей, которых в университетах не учат. Кое-что относится к тому, о чём вообще редко говорят вслух.
   
   


7. Система должна быть закрыта. То есть, далать умный софт должны люди, полностью знающие как и зачем он будет применяться.
   
   Если сжульничать с определением требований и просто добавить «настраиваемость и расширяемость», любой участник процесса, чтобы съэкономить пятнадцать минут работы, прау нажатий на клавиши или просто выпендриться, будет привешивать к системе дикие, несовместимые расширения. Причём, в половине случаев ошибочные не только по идеологии, но и по исполнению.
   
   


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

Comments

[norguhtar.livejournal.com]

Если сжульничать с определением требований и просто добавить «настраиваемость и расширяемость», любой участник процесса, чтобы съэкономить пятнадцать минут работы, прау нажатий на клавиши или просто выпендриться, будет привешивать к системе дикие, несовместимые расширения. Причём, в половине случаев ошибочные не только по идеологии, но и по исполнению.

И тут я сразу вспоминаю latex :)

[vit-r.livejournal.com]

Весь open source основан на самовыражении и самовосхвалении.

[ext_1684112 (from livejournal.com)]

>latex


maven тоже

[akuklev.livejournal.com]

Он бесконечно далёк от народа, бесконечно. Я не знаю ни одного специалиста, который нормально разбирается в Моделике, СисМЛе или Архимейте, и вообще присутствует на свободном рынке труда! Все мои ближние и дальшие знакомые этого уровня компетентности не только загружены работой по уши, но просто выкидывают в корзину для бумаги предложения по работе, потому что откуда взять в сутках ещё 24 часа? Это ведь всё амбициозные люди, они либо имеют свои крупные проекты, либо параллельно преподают. Если такого специалиста хочется заполучить какой-то фирме в свой проект, то даже при наличии уймы денег, надо ещё чтобы очень повезло и кто-то из таких специалистов в данный момент вообще был доступен. Студенты? Ну да, один на 1000, может быть. Вот недавно я работал с аспирантом, гениальный мальчик, Агду с Идрисом крутит и ассемблер PDP-11 ему не чужд, отличный специалист вырастет, так я было расслабился, поручил ему небольшой модуль целиком самому сделать, раз он такой умный. Ну ебать же колотить, что он мне написал, ну вообще у человека нет ни чувства стиля, ни чувства вкуса, ни понимания, в каком мире он живёт. Ладно бы просто код несопровождаемый, так он структурирован так, что невозможно как-то систематически оценить корректность. При этом входные данные вообще не проверяются, а эксепшены не хендлятся, прям будто их в реальном мире и не бывает никогда. И это гениальный мальчик. Сколько грабель и лет нужно, чтобы он научился писать нормальный код? Куда ещё один язык такого масштаба? Кому? Зачем? Кадров нет вообще.

[vit-r.livejournal.com]

Чего требовать от студентов, если их учат люди, никогда не видевшие промышленного производства софта?

Правильные учебники на эти темы закончились где-то в конце восьмидесятых.

А в фирмах - да. Будут выбирать по типу "В профиле стоит - значит эксперт". В результате кошмар, кошмар и тихий ужас. Но как-то работает. Правда ресурсы жрёт немерено, но для этого индусы есть.

Кстати, чего без абзацев?

[akuklev.livejournal.com]

> Чего требовать от студентов, если их учат люди, никогда не видевшие промышленного производства софта?

Это, вообще говоря, не так. Бывают преподаватели всё видившие. Только они прочли лекцию и ушли. Реально менторствовать, разбирая кусок написанного студентом кода, никто не будет.

> Правильные учебники на эти темы закончились где-то в конце восьмидесятых.
А они были, эти учебники, вообще? В смысле не "издавались ли", а применялись ли хоть когда-то?

А без абзацев просто потому сто слишком второпях писал комментарий.

[ailev.livejournal.com]

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

Мы так и Моделике, и Архимейту учили (SysML мы не рекомендуем). Просто у нас это типовая ситуация: постановка какой-то практики моделирования у клиента. Так что мы разного насмотрелись на разных предприятиях, разных стратегий решения вопроса. Опыт некоторый имеется.

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

[vit-r.livejournal.com]

Примерно через три месяца они обычно разбираются настолько

Пардон, но такого не бывает. Значит у вас там качество как-то не так меряется.

А языки создаются естественным путём. Поэтами и писателями.

[ailev.livejournal.com]

Качество меряется обычно: модели используются на производстве, и приносят при этом пользу.

Я понимаю, что Кобол создавался поэтами и писателями, естественным путём. Поэтому так долго продержался, и широко распространился. Жаль только, подвымер в последнее время, наверное народ более умный пошёл -- перешёл на Яву. Потом Ява вымрет как и Кобол, все перейдут на Хаскель, а передовики будут в это время заниматься Coq.

[vit-r.livejournal.com]

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

[akuklev.livejournal.com]

Широкая распространённость кобола, а теперь явы, как раз указывает на то, что вряд ли следующим будет хаскель. Хорошие продуманные языки начались далеко не с Хаскеля. Алгол'68 существует грёбанных 46 лет. MLю 31 год, ну это ладно, он функциональщина и немейнстрим. Но Оберону 28, при том что Оберон обычный императивный объектно-ориентированный язык по всем параметрам превосходящий Джаву, которая его младше на 10 лет и при этом дурнее в пять раз, не смотря на сто апдейтов.

[vit-r.livejournal.com]

Как сказал один спец по этому делу "Оберон - это язык, который был проще, чем надо"

[akuklev.livejournal.com]

В каком смысле? Оберон не страдает сверхвыразительностью, язык как язык. По-моему, Оберон (так же как Алгол-68 до него, тоже разительно выдающийся среди языков своей эпохи) просто вышел раньше своего времени, и не был пролоббирован ушлыми сейлзами.

[vit-r.livejournal.com]

Там в основе создания Оберона лежит высказывание Энштейна. А сказал человек, который делал компиляторы для Оберона 2 и прочих вещей.

А из Оберона-2 кучу вещей просто спёрли в Яву, забыв указать источник. У меня вверху среди ссылок есть про это.

[akuklev.livejournal.com]

Где вверху? Я у вас никаких постов про Оберон не читал.

[vit-r.livejournal.com]

Там где ссылки собраны должна быть и про Оберон 2

[akuklev.livejournal.com]

О, у вас оказывается есть верхний пост со ссылками. Я вас только во френдленте читаю, поэтому не видел раньше. Посмотрю при случае.

[akuklev.livejournal.com]

> Когда мы работаем в самой гуще народа, мы рекомендуем брать неглупых молодых специалистов, не потерявших вкуса к математике, но которые незнакомы поначалу с целевой предметной областью. Примерно через три месяца они обычно разбираются настолько, чтобы потом за очередные три месяца нанести непоправимую пользу нанявшему их предпринятию. Только нужно прислеживать, чтобы начальство их чем-то другим непрофильным не загрузило. Мы не раз так делали, получали отличные результаты.

Звучит отлично, но верится с трудом. Ну собственно верится в трудом только в три месяца. Обычно через три месяца люди начинают разбираться настолько, что могут сделать правильно только совершенно типовые вещи, минимально нетривиальные делают с каким-то количеством типовых и каким-то количеством уникальных, но очень грубых ошибок, а при попытке сделать что-то совсем нетривиальное либо несправляются впечетляюще катастрофически, либо имплементуруют знакомый им велосипед ("опытный программист на фортране может писать на фортране на любом языке программирования") с обилием самых извращённых костылей поверх предложенного им тула. Делать минимально-нетривиальные вещи научаются через полгода-год, делать совсем нетривиальные вещи в духе тула (а не наперекор ему) научаются через непредсказуемое время: одни через год, другим нужно 5-8 лет опыта, большинство же не научается никогда.

> С агрументом, что языкотворчество нужно прекратить, а если им заниматься, то нужно создавать языки не сложнее фортрана, я не согласен, ну да ладно.

Я этого не сказал.

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

Вы сами наверняка видели людей, которые вдруг резко начали "использовать ООП", изготавливая по классу под каждый метод, и ещё один дополнительный класс, содержащий 800 глобальных переменных. И людей, которые на функциональных языках программирования пишут императивщину где она нафиг не нужна, потому что кто-то умные сказал им что Хаскель лучше, забыв объяснить, чем.
Вот поэтому я и настаиваю на том, что сложные в изучении вещи останутся нишевыми; по крайней мере, пока уровень школьного математического и институтского программистского образования не скакнёт вперёд на полтора шага.


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

Потому что во-первых, мир чрезвычайно многогранен, а во-вторых изучить язык монструозной универсальности нормально мало кто может.
Поэтому вероятнее расклад, при котором имеется 100500 DSLей (простых по-отдельности) с которыми работают 95% программистов, 4% программистов, которые знают как делать междоменный интерлинкинг и 1% программистов, которые знают как делать хорошие DSLи.

[ailev.livejournal.com]

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

Другой вопрос, как сделать не слишком заумное и компактное обобщение. Это проблема, да. Но никто не говорил, что проблемы не нужно решать. Нужно. Языки подолгу разрабатываются ровно потому, что нельзя просто сложить разные фичи, полезные в разных языках. Онтологии тоже подолгу разрабатываются потому как онтологические выборы (3D время или 4D, например) бывают плохо совместимыми, и их нельзя накидать, как овощей в окрошку.

Лет пять ещё назад в области языкостроительства была относительная стагнация, а уже года два-три опять оживляж. Так что меня радует, что не мне одному в голову приходит создавать языки там, где раньше их не было.

Хотя у меня проблема -- три языка в одном (моделирования данных, запросов и мэппинга), так что непонятно, как подступиться. Но дорогу осилит идущий.

[vit-r.livejournal.com]

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

Вот это-то далеко не факт.

Любой стандарт, как и любая upper ontology - это коммерческая борьба за рынок и подчинения других своим решениям. Не теоретически, а на практике.

так что непонятно, как подступиться.

Хорошие вещи получаются, когда есть практическая задача и инструмент создаётся для её решения.

[vit-r.livejournal.com]

и научиться "достигать на этом языке цели чтоб оно как-то работало" путём компоновки готовых конструкций через пень колоду

Сейчас дофига народу работает по принципу Google-copy-paste Даже несколько типов взломов на этом построены.

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

во-вторых изучить язык монструозной универсальности нормально мало кто может.

В-третьих, чем больше монструозность, тем больше ошибок, кривизны и скрытых зависимостей. В конце концов всё это превращается вмагию

[akuklev.livejournal.com]

> В-третьих, чем больше монструозность, тем больше ошибок, кривизны и скрытых зависимостей. В конце концов всё это превращается вмагию

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

[vit-r.livejournal.com]

В электроснабжении работают инженеры ;-)

[akuklev.livejournal.com]

В программировании, к счастью, тоже иногда попадаются.