Если в стане разработчиков разброд и шатания, то другого результата и быть не может.Сообщение от capzap
Нет у разработчиков четкой идеологии и представления о предмете.
Если в стане разработчиков разброд и шатания, то другого результата и быть не может.
Нет у разработчиков четкой идеологии и представления о предмете.
Последний раз редактировалось Вольд; 30.08.2017 в 13:34.
есть хорошая статья по поводу изолированности разработчиков, от таких как Вы https://habrahabr.ru/company/retailrocket/blog/336430/, жаль что модераторы не придерживаются такого принципа
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Эта статья для разработчиков и про разработчиков OL.
А связывать меня с проблемами в OL просто смешно. Это бред сивой кобылы.
Последний раз редактировалось Вольд; 30.08.2017 в 14:05.
Наконец нашли виновного в проблемах ОЛ!
Если проблему можно решить за деньги, это не проблема, это расходы. Бог каждому посылает проблемы по его силам. Так что одно из двух. Либо ты можешь-таки
справиться с проблемами, либо это не твои проблемы.
внимательно ознакомтесь с моим постом, для тех кто в танке даю ключевые слова:
изолированность - разработчик не должен сидеть здесь на форуме и по каждой хотелке принимать какие то активные действия, если она пройдет все барьеры, то до него должны довести планы реализации этой хотелки
таких как Вы не относится персонально к кому либо
виновны все кто пытается пропихнуть свою хотелку не задумываясь к каким последствиям это может привести, результат уже виден одного такого действия
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Для одного разработчика хорошо работают одни подходы, для 7-и разработчиков другие, для 49 тоже другие, а 343 совсем другие. Спонтанно ли рос ОЛ или ещё как -- не так важно.
Предлагается, всё-таки в данной ветке обсуждать "Фичи и баги OWEN Logic". Выстраивание процесса в крупной компании к данной теме не относится.
Я поднимал вопрос о "составлении спецификации на вычисление схем" т.к.:
1) Линии задержки, обратные связи и макросы являются стабильным поставщиком "непоняток" при работе с ОЛ
2) Слова представителей ОВЕН весьма туманны. "Убрана прозрачность макросов", "у вас вместо линии задержки получилась обратная связь" и так далее.
На мой взгляд, спецификация может с одной стороны снимать вопросы "почему схема работает, а как заворачиваю половину в макрос, то перестаёт", и с другой служить документацией. Если честно, меня удивляет, что нет описания алгоритма по которому вычисляется ОЛ схема. Постоянно звучат слова "промышленность", "надёжность", а как вычисляется схема никто не знает и всех устраивает режим "как карта ляжет".
Так же, наличие спецификации позволит искать ошибки на уровне этой самой спецификации. Сейчас можно лишь гадать как ОЛ производит вычисления. Было бы описание -- можно было бы придумывать контрпримеры.
Судя по словам wal79, описание алгоритма вычисления схемы либо вообще не в планах, либо не в приоритете. Ну и ладно.
На всякий случай, вышеописанное ^^^ напрямую относится к "багам ОЛ". Например, оно пересекается с
Не путайте "корреляцию" (correlation) и "причинную связь" (causation). Если знаете о критических ошибках, то пишите их в эту тему. Как раз тема для этого и существует. А обтекаемые формулировки "пошли критические ошибки" и "каким последствиям это может привести, результат уже виден одного такого действия" незачем сюда писать.
Предлагаю озвучить все ники не пишущие в этой теме про фиксы и баги, чтоб это было объективно,а не попытка заткнуть рот оппоненту
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Каждый думает в меру своего развития. Что я подразумевал под спонтанностью. Первоначально были предъявлены определенные требования к продукту ОЛ. Согласно этим требованиям была разработана архитектура приложения. Требования были просты и задачи перед продуктом ставились простые. Увидев
положительную реакцию пользователей впоследствии стали ставиться все более накрученные требования. Политика была направлена на обратную связь от пользователей. Да, курс продукта менялся, иногда даже слишком кардинально. Иногда доходило до кардинальной переработке архитектуры и знаний о предметной области. И до сих пор мое мнение не изменилось насчет обратной связи. Что продукт прежде всего должен учитывать желание рынка, пользователей. Конечно вы должны понимать что кардинальные перемены в архитектуре влекут за собой баги. Проблема ОЛ в том что он выходит на рынок сырой, так сказать с пылу жару. Вы можете критиковать разработчиков как угодно. Может лоджику далеко до каких-то других продуктов конкурентов. Но этот продукт имеет немаловажный плюс: реактивность обратной связи пользователей. Лоджик создавался как продукт в котором легко создавать алгоритмы простой и средней тяжести. Такое было одно из требований. Поэтому многие вещи скрыты от пользователей. Можете дальше ругать лоджик и разработчиков на чем свет стоит. Понятно, что всем не угодишь.
программер
Ваше желание противоречит одному из требований: макрос должен себя вести также как в редакторе в режиме симуляции. Это касается макросов с ЛЗ, потому что если их нет, то и говорить не о чем, я думаю вы это и так понимаете. Так вот, Для выполнения этого требования при встрече макроса на своем пути анализатор вычисляет его полностью один раз. Алгоритмы те же самые что и у схем проектов. Логика проста. Но в чем преимущества ЛЗ? В том что они выполняются в высоком приоритете. Именно это дает эффект выполнения обратной связи, которую задумал пользователь. Так вот, если вы задумали какой-то алгоритм обернуть в макрос, то нужно понимать, что это "закрытый" будет алгоритм, что он будет вычисляться как отдельная схема. Надеюсь, понятно разъяснил.
Давайте уже на этой разъяснительной ноте остановимся.
программер
Ну, на самом деле, противоречия тут нет.
Противоречие есть с другим.
С тем, что анализатор схемы считает макрос функцией, а макрос с лз или обратной связью таковым не является.
Так же, как не является функцией любая схема "помнящая" своё состояние.
Вот поэтому он ("анализатор") и паникует, обнаружив "обратую связь вокруг функции", и подставляет вместо неё ещё одну лз.
Вариант "прозрачности", с сохранением однозначности работы схемы и макросов в схеме и в отдельном редакторе, есть, но он требует другого подхода к макросу. Это не функция, а схема, вставленная в "главную" схему (макроэлемент, объединяющий множество элементов и связей, имеющий условное графическое изображение), и для анализа всей схемы необходимо его каждый раз вставить целиком, после чего уже анализировать полную схему на наличие возможных неоднозначностей и "обратных связей" без лз.
Ваши права
Ответить с цитированием
