Рубрики
Софт

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

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

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

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

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

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:Задача vs Решение, Декларативное vs Императивное

TODO: Возможно начать с того, что инжиниринг нацелен на решение проблем.

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

Первый пример кажется надуманным, но это реальные проблемы, которые встали перед ИТ индустрией в последнее десятилетие с активных появлением многоядерных процессоров на наших рабочих столах. Программисты писали императивно «Перебираем от 1 до 1000 с шагом 1» или «перебираем по одному, пока не закончится» и т.п. Такие выражения не масштабировалось. А вот те языки, где было выражения «Для всех в данном множестве» — получали шанс.

И здесь получается подвязывается абстракция/имплементация. Нужно правильно описать задачу.

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

TODO: Аспекты

TODO: Inbox

  • Виртуализация. Расширяет наши возможности давая то, чего нет, из того, что есть. 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 не будет опубликован. Обязательные поля помечены *