Рубрики
Софт

Дайте мне точку опоры и я… постараюсь не упасть

Как можно назвать это дурацкое состояние, когда занимаешься чем-то не первый десяток лет, но чем дальше, тем тяжелее даётся объяснение того, чем же ты всё-таки занимаешься? IT, программирование, software engineering, software development, solution engineering, computer science, data science, кодинг… Кто же я такой есть?

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

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

Этот гордиев узел необходимо разрубить и начну я с того, что устрою виртуальную встречу всех этих «специалистов». Представлю, что они участвую в конкурсе на выполнение некоторой нетривиальной задачи.

Программист

TODO: Программа — условно текст на некотором языке. Предназначенный для коллектива, человека, компьютера. То есть всё во многом определяется знанием этого языка. Есть умение на нём писать, но что оно даёт? Могу представить себе «умение писать на английском языке». Что делать с этим навыком? Это умение писать романы, научные работы, переводить с другого языка? Забегая вперёд можно представить конкуренцию.

TODO: Программа — это просто продукт. Программирование — это как…

Предмет деятельности

TODO: Переделать на принципиально новую статью задающуюся вопросами образования? С чего учить. Вроде бы хочется научить среднего сына, некоторых алчущих друзей, помогаю крестику, недоволен текущей системой. По хорошему я не видел ни одной книги или сайта, про которые бы я мог сказать «вот оно». mess://xde.gym.language.

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

TODO: Есть интересные размышления «алгоритмисты vs структуралисты».С примером про то, как мучительно переезжал «for» на многоядерные системы. Он тоже может отразить образовательный процесс. Они же пересекаются с другими размышлениями «информатика vs программирование vs кодинг vs software engineering vs computer science». А выбор здесь может во многом обсуславливаться дилеммой «декларативный vs императивный». Ведь суть, всё-таки в решении задачи и у одной задачи их может быть много, где-то даже CS проедет мимо. А это уже связано с абстракцией и имплементацией. Возможно всё сводится к вопросам «что делать» и «как делать».

  • Найти все заметки про декларативное и императивное
  • Скорее всего мне надо начинать от понятия «задача», которое будет выходить на декларативные описания и сочетаться со старой парадигмой «хорошо записанное условие задачи — уже половина решения». Как показывают типо-ориентированные языки, это может быть полным решением.
  • Прокомментировать, что в современном мире компиляторы настолько хороши, что конкурировать с ними в понимании аппаратной реализации непросто. Поэтому на данный уровень стоит спускаться только если знаешь что делать (это если глубоко) или делать постоянно небольшие погружения (в тему интеграции VS+MASM и т.п.). Имхо, хорошо настроенный декларативный аппарат в мозгу поможет изучать и компьютерные внутренности. Сюда же в качестве примера можно привязать и SQL (когда под капотом могут быть индексы, колумнары, партиционированные по разным компьютерам и т.п.).
  • Например — отправить электронное письмо. Может быть далеко не один способ решения этой задачи. И вообще у одной задачи может быть несколько решений.

TODO:Системное программирование — про реализацию. Нельзя уделять ему повышенное внимание, поскольку системы могут менять. Что интересно, в начале учат системному, а потом отделять — реализацию от абстракции.

TODO:Абстракция «снимает» с предмета рассмотрения лишнее, не нужное в рассматриваемом случае. А значит, остаётся только самое важное. Что вполне можно назвать спецификацией.

TODO: Примеры с арифметикой, стулом, ноутбуком. Притча про мудрецов, сочетание с аспектами. Может аспект и есть абстракция? Одно — процесс, другое — результат.

TODO: Inbox

  • Есть Information Officer, значит должен быть Information Engineer и соответствующий информационный инжиниринг. И тесная работа с DIKW.
  • Solution? Кто должен принимать решение, что программа не нужна? Может формализация (Информация, ИТ) постепенно и приводит к решению задач. Как типо-ориентированное программирование, декларативное программирование.
  • Виртуализация. Расширяет наши возможности давая то, чего нет, из того, что есть. https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C
  • Возможно отдельно, возможно нет, стоит рассмотреть в в одном контексте ООП, ФП, SOLID. Показать, что SOLID — это не только ООП, согласно его же идеям. ФП — не стоит рассматривать как god-класс и т.д.
  • Чтобы не путаться в терминах вроде интерфейса, абстракции, контракта и т.п., можно свести всё к термину «спецификации», «спекуляции», «спеки», «специфики»,… в общем поиграться со «speculo». Даже посвятить её отдельную главу «Есть хороший латинский термин speculo, мы его часто встречаем в терминаз спецификация, аспект и т.п.».

Навигация по теме

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *