Category: дизайн

Category was added automatically. Read all entries about "дизайн".

flow

Основы понимания дизайна языков

За последние 20 лет я исследовал сотни языков программирования и описания данных. Включая не только хоть как-то известные, что применяются сейчас или доступны в исторических материалах, но и множество DSL, которые (обычно без какой-либо документации) встречались в софте, играх или продуктах демосцены.

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

Но сейчас, в недавних разговорах, я всё же подобрал хороший рецепт. Последовательность такая:
1. Изучить материалы HOPL ( https://en.wikipedia.org/wiki/History_of_Programming_Languages ).
2. Исследовать языки из свежего Top 20 TIOBE ( https://www.tiobe.com/tiobe-index/ ). Update: Коллега в чатике верно подметил, что картину сегодняшнего дня лучше отражают данные Stack Overflow, так что вместо TIOBE можно брать их ( https://insights.stackoverflow.com/survey/2017#technology ).

Разумеется, там есть лишнее. И нет ряда языков более актуальных, как в исторической перспективе, так и сейчас. Но это не важно. Важно начать с какой-то точки, и далее личный интерес обеспечит дальнейшее развитие.

В этом смысле показательны материалы HOPL. Если при прочтении у вас возникнет ощущение "сложно, но интересно" - продолжайте. Если же это будет ощущение отторжения - ок, стоп, значит не ваша тема. Вообще, или на данном этапе жизни.

Если что: можно не разбираться в языках программирования, не понимать их как явление, но при этом быть успешным "программистом на знакомых языках и готовых фреймворках". Это не плохо и не хорошо. Разные ситуации требуют разных навыков и интересов.
flow

Паттерны часть 1: вредные

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

Сначала о плохих паттернах. Есть такой термин "design patterns" (шаблоны проектирования), изначально нейтральный, но в сфере разработки программного обеспечения имеющий особое наполнение и особую дурную славу.

Все люди разные. Кто-то лучше танцует, кто-то доказывает сложные теоремы. А психика некоторых позволяет в больших количествах выдумывать сложность на пустом месте. Бюрократы-законотворцы, стандартизаторы W3C, консультанты по CMMI, программисты-чемпионы по KLoC кода - это всё их ниши, где они могут в промышленных масштабах вредить человечеству, сохраняя полную уверенность в полезности своей деятельности.

Тема design patterns, начиная с одноимённой книги 1994 года, это ещё одна кормушка для таких людей. Передача функции сравнения в функцию сортировки или установка коллбэка - слишком просто. А если придумать термин "dependency injection" и убедить леммингов писать для этого отдельные фреймворки, то можно поднять денег на книгах, выступлениях и консалтинге. Разделяемое состояние для обеспечения какого либо функционала программы - что может быть проще? Но если его назвать "singleton pattern" и положить не в app.renderer, а в Bla.Bla.Bla.Renderer.getInstance(), а затем убедить леммингов в религиозной необходимости данного шага, то создаётся целый пласт новых проблем (ведь состояние становится бесхозным), которые можно изучать и усугублять десятками слайдов.

Тлен, безысходность и бесчисленные повторения многокода - вот вся суть design patterns.

Что же касается хороших паттернов, то о них будет следующий пост.
flow

Версии

Реально существующая проблема: http://dtf.ru/blog/read.php?id=69122
Существует множество решений, которые помогут вам организовать работу с версиями 100500 маленьких текстов/исходников. Однако, для больших файлов всё иначе.

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

А уж идея "прогрессивных" авторов Git/Mercurial о том, что надо таскать за собой полный репозиторий в таком контексте выглядит совсем чудесато. Если это репозиторий типа "спецэффекты фильмы Tron 8", то на фирме не найдётся ни одного отдельного компьютера, куда может поместиться всё это добро с кластера.

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

Хорошая ниша для стартапа, кстати.
flow

Ontology and AI

John McCarthy, более известный как создатель Lisp, также был и остаётся одним из наиболее компетентных специалистов в области искусственного интеллекта.

Из Artificial Intelligence and Philosophy «Quine wrote that one's ontology coincides with the ranges of the variables in one's formalism. This usage is entirely appropriate for AI. Present philosophers, Quine perhaps included, are often too stingy in the reifications they permit. It is sometimes necessary to quantify over beliefs, hopes and goals. When programs interact with people or other programs they often perform speech acts in the sense studied by Austin and Searle. Quantification over promises, obligations, questions, answers to questions, offers, acceptances and declinations are required.»

Наводит на мысли. Онтологии и AI очень тесно взаимосвязаны. Некоторые проекты (Cyc) одновременно позиционируются в обоих областях. Но есть ключевое различие в analysis and design.

Репутация термина AI изрядно подпортилась во время AI winter, хотя потихоньку восстанавливается проектами вроде IBM Watson. Но весь design относится именно к AI, решается задача получения как можно более полезных выводов с наименьшими затратами на исходные данные.

С другой стороны, сейчас период большого онтологического хайпа. Средняя онтология это какой-то кусок данных в OWL с формальной проверкой непротиворечивости (Semantic Web), приличная онтология (смотреть BORO, ISO 15926, Gellish, ...) - analysis предметной области, с поправкой на неработающие модальности. Анализ выявляет основные качества предметной области и позволяет сделать правильный дизайн.

Однако, напрямую использовать результаты анализа вместо дизайна нельзя - это приводит к абстрактным датасетам, которые можно распечатать и обклеивать стены, и из которых теоретически можно получить какие-то выводы, затратив пару миллиардов лет машинного времени. Но и автоматически построить дизайн из онтологии тоже нельзя. От онтологии до дизайна - как от альбома "Архитектура древней Греции" до проекта реального здания. И здания будут очень разные.

Отсюда философские вопросы:
1) Если машиночитаемые данные совместимы только при совместимых дизайнах, то какой смысл в стандартизации любой онтологии-без-дизайна?
2) Надо ли описывать онтологии на каком-либо формальном языке, если формальная проверка онтологии не снижает затраты на формальную проверку дизайна?
3) В правильную ли точку я направляю свои усилия в данный момент?
flow

Пределы совершенства

( Навеяно темой "мощных языков" в http://wizzard0.livejournal.com/205020.html )

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

Любые мощные инструменты программирования - Python вместо Java, etc - лишь отказ от лошадей/кодеров. Вся работа с предметной областью, анализ проблемы и дизайн продукта, остаётся в силе. А юзабилити, UX, внутренняя архитектура, документирование и упаковка требуют принятия такого же количества решений, как и при использовании слабых технологий.

В этом и состоит одно из проклятий Lisp, Smalltalk и других эффективных, но маргинальных средств. Чем компактнее код, тем меньше времени надо тратить на него. Следует вложить ресурсы в анализ предметной области и дизайн. Тем более, что они (в отличие от кода) несокращаемы. А если "программисты очень любят программировать", то мы наблюдаем именно тот дизбаланс, что творится в упомянутых языковых коммьюнити.

Успех некоторых современных языков - следствие их продукт-ориентированности. Стандартная поставка Python с каждой версией включает в себя новые готовые компоненты (sqlite3, ctypes, ...), а уровень документированности делает бессмысленным написание дополнительной обучающей литературы по самому языку (но не по его применению в какой-то предметной области, разумеется).

Серебряная пуля всегда есть. Для кода. Но не для продукта.

P.S. По текущему проекту сейчас столько всего... Очень хочется команду с отдельным юзабилистом.