Pull to refresh
0
Игорь Проскочило @Kibitz read⁠-⁠only

Программист, С#, CodeNotion, онтологии

Send message
Ваша статья мне очень понравилась, поскольку сразу же нашла отклик в моем собственном опыте и припомнились предыдущие обсуждения по теме.
Есть у меня такое хобби — собирать по статьям мудрые высказывания людей (в том числе из комментариев), как говорится «все уже сказано до нас», поэтому просто приведу цитаты которые на мой взгляд стоит упомянуть в контексте данной статьи.

цель -> архитектура данных -> код. Здесь порядок менять ни в коем случае нельзя!

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

Копирование сущностей реального мира и попытка приклеить к ним потом скотчем поведение — это одна из самых распространенных ошибок ОО-дизайна.

ООП-проекты обычно выглядят не как качественно спроектированные хранилища данных, а как огромные спагетти-графы объектов, указывающих друг на друга, и методы, получающие огромные списки аргументов. Когда вы начинаете проектировать объекты Context просто для того, чтобы урезать количество передаваемых туда-сюда аргументов, то понимаете, что пишете настоящий ООП-код уровня Enterprise.

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

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

В любом бизнесе НУЖНА МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ.
Если вам её не дают, обратитесь к непосредственному начальнику. Если вам говорят, что её нет, не верьте. Она есть, просто кто-то должен упорядочить хаос. Есть такие люди – конструкторы, проектировщики… они как бы должны. Еще раз: вам нужна модель. Иначе вы и ваш софт умрете. Поддерживать тучу глобализмов невозможно. Либо так: надо уволиться раньше, чем он умрет.Но проблема вот в чем. Разработать модель бизнес-процесса очень сложно. Бизнес постоянно меняется и это не математика (не создали ещё такой). Математики здесь опустили лапки и сейчас предпочитают принимать зачеты у студентов в ВУЗах. Поэтому прикладным программистам приходится “как-нибудь так”, как говорила незабвенная Масяня.

Мы должны задавать вопросы и требовать от экспертов более подробного описания их терминологии, либо смены формулировок, или даже использовать некие аналогии. Одна из моих любимых «игр» — это спросить экспертов о том, как бы они делали свои задачи в отсутствие компьютера. Что будет действиями, а что объектами, предметами, концепциями или существительными?

Процесс разработки ПО — это перевод описания и требований предметной области на формальный язык. Для упрощения процесса и устранения неточностей разработчики должны создавать, развивать и использовать язык предметной области

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

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

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


И еще немного от себя.
«Под архитектурным слоем подразумевается определённый набор логики, то есть деталей приложения, которые позволяют реализовать пространство прикладных задач заданного уровня» — здесь Вы скорее всего даете определение DSL, и в частности Языково-ориентированное программирование(LOP). При этом, я был бы рад что бы эталоном построения архитектуры стал LOP.
Есть возможность подготовиться к критикал багу на проде — подготовить стабильный протестированный код перед заливкой )
жаль, идея хорошая, а имеющиеся реализации полный отстой(
так и не нашел нормального…
Tree Style Tab!!!
Именно то, что я предложил в комментарии выше, но даже не допускал мысли погуглить нечто подобное, а оно существует) жаль только Firefox не люблю, но есть аналоги по хромиум, буду тестить, спасибо!
Также автоматически группировать старые вкладки по дате открытия/сессии, виртуальные каталоги, при наведении курсора отображается вертикальный список полных заголовков страниц, где первыми отображаются страницы с которых и началось все ветвление.
В свою очередь, такие каталоги можно тегировать (работа, интересное, почитать позже, тикет 100500)
Отлично расписали! теперь бы разрулить все это)
Учиться и ещё раз учиться
очень частый кейс, когда из одной статьи по ходу чтения закидываешь в фоновую закладку несколько ссылок или просто перетаскиваешь текст для авто-гугления. В этом случае считаю логично группировать такие вкладки (открытые с одной страницы). Так можно будет понять к чему вообще относится данная страница (контекст интереса к ней).
А если организовать это иерархически, то все само как бы по вложенным каталогам разбивается, и видна история развития ситуации. Даже отображать такое дерево на всплывающей боковой панели (линейный список вкладок вообще тогда бессмыслен)
Не согласны так несогласны, ваше право)
Но
Дайте тогда хоть собственное определение, обязательно поучаствую в его обсуждении.
В большинстве случаев даже четкой границы не провести: каждый метод или оператор, в сущности, говорит что сделать, а не как (как — сокрыто в его реализации), не говоря уж о более сложных конструкциях.
Сокрытие деталей реализации в методе или операторе — это способ повышения абстрактности (но никак не декларативности), на уровне языка (оператор) или на уровне конкретного проекта (метод), иерархически повышать его можно сколько угодно.
Декларативность кода состоит в том, что он "не используют понятия состояния, в частности, не содержат переменных и операторов присваивания", «на повышение уровня декларативности нацелено языково-ориентированное программирование.»
вы меня обвили в том, что проблема «Комбинаторного взрыва» вообще не имеет отношения к декларативному программированию и ссылаетесь на концепцию «Программирование в ограничениях»
на самом деле это ваша трактовка данного
Но когда вы отождествляете создание механизма решения задач и сопутствующую проблему комбинаторного взрыва с парадигмой программирования — это крайне глупо.
Не стоит смешивать в одно парадигмы программирования, классы задач, специфические проблемы, если уже давно есть конкретные направления работающие на стыке всего вышеперечисленного (подсказка: это «Программирование в ограничениях). Хотя это лишь моя попытка увязать изложенное вами в данной статье, и похоже вы и сами четко не знаете о чем это все, т.к. нет описания конкретных задач, четкого теоретического обоснования.
в тех предметно ориентированных языках, где «механизм поиска решений» реализован, при определенных условиях могут возникать сложности с поиском решений
аналогичное по сути утверждение в отношении математики возможно покажет бессмысленность такой постановки вопроса.
— в целом математика очень хорошо помогает решать большинство задач, но некоторые проблемы все еще остаются нерешенными.
Не видел от вас никаких примеров по теме «программирования в ограничениях».
Если что, то предметная область SQL к данному классу проблем не относится)
С вики все норм, просто даже после того, как вы прочитали что это такое, не поняв сути, строите на его же основании контраргументы вполне разумному замечанию:
Программирование в ограничениях — наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Вам примеров из википедии мало?
Очень похоже что ваш абстрактный «механизм поиска решений» это разновидность кнопки «сделать все хорошо», без какой либо конкретики, только акцентируя на проблеме полного перебора.
Вот только все они завязаны либо на свою предметную область, либо привязаны к конкретному языку программирования
что SQL что Пролог как раз языки под конкретную предметную область — то есть предметно ориентированный язык (DSL), никакого «либо» здесь не может быть.
Более того «механизма поиска решений» который реализован в некой среде выполнения (сервер SQL или алгоритмы Пролога) сам по себе не решит на обум вашу задачу, для этого, вам необходимо еще и дать очень детальное и непротиворечивое описание конкретно вашего частного случая.
Для пролога это внесение набора предикатов, для sql это описание структуры таблиц и их связей, а универсальный «решатель» это уже из области фантастики, без знаний о предмете, ни один алгоритм не может быть полезен.
Лол, вы до моего комментария не знали о существовании программирования в ограничениях, иначе бы хоть как-то упомянули его в своей статье, а теперь мне же цитируете вики по данной теме)

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

За языком SQL как раз стоит отличная реализация механизма решения задач, но как и всякий механизм его можно сломать — т.е. не понимая базовых принципов работы таки сделать ему комбинаторный взрыв (перемножить две таблицы по миллиарду строк, ну это диверсия а не проблема языка). Вот как раз ваш же пример основывается на том как сломать механизм своим невежеством
Но если запрос оптимизировать не получается (например, нет индекса по нужным полям),
когда это за наличие необходимых индексов стал отвечать SQL?! При этом адекватный запрос и без индексирования успешно выполнится, это как раз уже вопрос оптимизации, при чем формальной и без тупого перебора вариантов.
Странный ход мыслей, делать интерфейс к реализации которой еще нет)
К декларативному стилю написания программ следует относить и язык структурированных запросов (SQL)
основное применения языков программирования в декларативном стиле — отказаться от необходимости описания четкого алгоритма поиска решения, отдав это компьютеру на откуп. Для которого самое простое решение «в лоб» — полный перебор возможных вариантов.
Именно в этом случае и начинается экспоненциальный рост времени выполнения алгоритма.

вы рассказываете о какой-то теории большого «Комбинаторного взрыва» вообще не понимая что это такое, и что к декларативному программированию это совсем не имеет отношения.
в противном случае никто бы не использовал SQL (некоторые задачи решаемые в рамках его предметной области могут привести к «взрыву» комбинаций которые необходимо обработать, но это совсем другой вопрос).

Программирование в ограничениях наиболее адекватный общий знаменатель ваших рассуждений с применением понятий «логическое программирование», «комбинаторный взрыв» и «декларативное программирование».
Если говорить прямо о шизоидах в контексте статьи
В статье о них говорится как раз в контексте профессиональных качеств, то, как их особенности проявляются в работе. Это не шизоиды в контексте статьи, а статья о шизоидах в профессиональном контексте
причинно-следственная связь характера и поведения увязана только с профессиональным навыками
характер есть причина поведения? а может все таки тип характера определяется на основе поведения? Разве автор пишет инструкцию как руководителю определять психотип по наблюдаемым навыкам? эффект Барнума не просто так упомянут.
Не приведено семейных отношений, а значит, исследование не полное
Статья отличная, но только это не исследование, на полноту и не претендует. Причины акцентуирования в ней не рассмотрены, как и не расписаны все роли по абзацам «Шизоид как [папа|мама|прохожий|сосед]»
всех проблем в жизни человек решить не в состоянии
Для этого абсолютно любой человек имеет набор психических защит
Поэтому он пытается от них уйти.
Не всегда это уход — интеллектуализация, рационализация, это попытка справиться с проблемой, не столько решить ее, но изменить свое отношение к ней, и дальше ее уже как бы и нет. Именно такой формат работы с переживаниями и формирует описываемые в статье качества, являющиеся предпосылкой к занятию наукой, где все понятно и многое поддается контролю, что уменьшает шанс возникновения новых проблем, а не бегство от имеющихся в
Чтение ли газет, игрозависимость, алкоголь, измены ли
Решает ли такое забытьё проблемы индивида? В статье как бы решает
Психологические защиты ничего и не должны решать — они защищают
Все ли люди, не желающие возвращаться на конвейер, шизоиды? Если читать статью, то между строк можно сделать такой вывод.
Не стоит сильно вглядываться в междустрочие… наверняка такому тоже есть название, возможно автор скажет.
Остро) Лаконично.
Но все же статья о том, что приравнивать шизоидов к шизофреникам нельзя.
Проще — не создавать accidental complexity. Не городить паттерны ради петтернов, слепо веря что применив их в узком контексте конкретной задачи ты обеспечиваешь некую «расширяемость».
Писать просто — трудно. Не важно в какой парадигме.

Для простоты можно писать процедурно
Категорически не согласен. Просто писать — возможно, но вот читать потом такой поток сознания это очень сложно (непонятно).

То, что написано без усилий, читается без удовольствия
В контексте данной статьи, весьма важным есть то, как эти два множества формируются.
«Дешево» — подразумевает наличие каких-либо сумм денег, следовательно повышается вероятность что именно профессионализм, уверенность в своих знаниях, мотивирует человека на беспристрастную оценку в рамках своих компетенций.
«Бесплатно» — для рецензента априори не стоит вопрос финансовой выгоды, следовательно повышается процент фанатичных личностей которым просто больше всего надо, и они часто готовы бесплатно тратить свое время на бессмысленную оценку очередного билета в грантоедство. Яркий пример — Википедия, где часто встречаются статьи которые больше дезинформируют нежели распространяют истинные знания.
1

Information

Rating
Does not participate
Location
Сумы, Сумская обл., Украина
Date of birth
Registered
Activity