«Замыливается глаз» — это от неправильной мотивации. Когда я в ЦУПе начинал программировать такой профессии — тестировщик вообще не было. Но была персональная ответственность за код, вплоть до статьи УК «халатность». И если коллега находил в моей программе баг, я ставил ему коньяк.
Обычно оценка трудоемкости имеет плотность распределения вероятности с длинным правым хвостом. Длина хвоста пропорциональна неопределенности в задаче. А где неопределенность, там риски. Мне как руководителю, надо знать риски, чтобы адекватно ими управлять.
Спасибо за информацию! Просмотрел презентацию — очень похоже на то, о чем я написал в посте. Буду изучать внимательнее. Разработкой игр не занимался, но десять лет разрабатывал имитационные модели сложных систем — тысячи объектов с десятками компонентов в каждом. Мои идеи зародились именно при разработке этих моделей.
Вот Вы явно не в своей тарелке — по образу мыслей философ, а в профиле:
О себе: Эксперт. Проектирование и разработка программного обеспечения
Может не тем занимаетесь? :-)
Просто всему — свое время. «Время разбрасывать камни, и время собирать».
Если бы нас в свое время учили философии (не только марксистко-ленинской), психологии, лингвистике, семиотике, мне кажется, мы могли бы более эффективно проектировать и разрабатывать ПО. Но нас учили, ТФКП, функциональному анализу, квантовой механике и много-много чему еще. Все это было очень интересно, но, к сожалению, в моей программистской карьере не пригодилось :(
Я не говорил, что пользователь CAD системы что-то должен писать на DSL. ИМХО, у пользователя должен быть графический редактор с набором готовых компонентов, из которых он конструирует решение своей задачи. А вот из того, что он сконструирует, должен генерироваться код на DSL. Где-то так…
> Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Ни в каком. Потому что и то и другое, представляет собой то что в философии науки называют «знание» и измеримыми сущностями они не являются (опять же по Шеннону), хотя включает в себя некий набор информации.
А вот если мы говорим о законах, как о неких мат. моделях, которые можно закодировать на некотором формальном языке и куда-то передать — то вот тут уже можно что-то измерить.
Информация, знания, данные… Это очень интересная тема. Думаю заслуживает отдельного поста. Как нибудь соберусь с силами и напишу. Там и продолжим обсуждение.
Количество информации по Шеннону это мера пропускной способности канала связи. К самой информации формула Шеннона отношения не имеет. Вот посуди сам: в каком законе больше информации – в Законе Ома или во втором законе Ньютона?
Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает. И его имитационные модели, кстати, тоже.
Ну, 20 лет проработал в ЦУПе. Имел честь участвовать в проектировании того, что летает до сих пор. Так вот, там мы проектировали на основе законов баллистики, аэродинамики, того же сопромата и много еще чего. В программировании похожих законов пока (?) нет. И мы продвигаемся к решению методом проб и ошибок. Поэтому и считаю некорректно сравнивать проектирование ПО и космических аппаратов.
«Бросая в воду камешки, смотри на круги, ими образуемые...» ( (с) Козьма Прутков) — это тоже про обмен информацией?
А, ничего что, Шеннон писал применительно к техническим системам, лишь о сигналах и связи, да еще при этом сам указывал, что информация, которая передается этими сигналами, его не интересует. А ты говоришь, что он ее определял.
Заметь, ты приводишь в основном примеры системного программирования = программирования для программистов, если хочешь. Мне кажется, что программист-космонавт Чарльз Симони был совершенно прав, когда говорил: «programmers become unwitting cryptographers». Системное программирование не создает пользовательской ценности, а лишь облегчает (всегда ли?) ее создание для прикладных программистов.
Сожалею, но многого не понял. Готовы пояснить хотя бы вот это:
> Еще одна странность ООП: «Поведение — это то, как объект действует и реагирует; поведение выражается в > терминах состояния объекта и передачи сообщений». Но, постойте, если я моделирую столкновение двух
> автомобилей то, кто из них и какие получает и передает сообщения?
Никаких странностей, см. классическое определение информации по Шеннону.
Какая связь краш-теста и определения информации по Шеннону? И почему определение, например, не по Винеру?
Есть такой поведенческий паттерн: «Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.» От ответа воздержусь. Но вопрос задать очень хочется. Что такое «атмосфера наукоемкого программирования»? Просветите?
Ну, для меня промышленное программирование больше похоже на написание за три месяца романа «Евгений Онегин» командой из двадцати вчерашних студентов под руководством системного архитектора А. Пушкина. Программирование гораздо меньше напоминает создание домов, мостов и космических аппаратов.
Центр тяжести технологий программирования уже давно смещается с построения эффективных алгоритмов в сторону построения эффективных моделей предметных областей. ИМХО, сложными математическими алгоритмами (которых нет у Кнута) занимается лишь небольшая когорта избранных (завидую белой завистью!). Но подавляющая часть программистов занимается более прозаическими вещами. И любое новшество с точки зрения более лаконичного отражения логики предметных областей сможет дать ощутимый выигрыш в эффективности нашей индустрии.
Просто всему — свое время. «Время разбрасывать камни, и время собирать».
Если бы нас в свое время учили философии (не только марксистко-ленинской), психологии, лингвистике, семиотике, мне кажется, мы могли бы более эффективно проектировать и разрабатывать ПО. Но нас учили, ТФКП, функциональному анализу, квантовой механике и много-много чему еще. Все это было очень интересно, но, к сожалению, в моей программистской карьере не пригодилось :(
Да, именно в играх активно развивается Anemic Domain Model, о которой я упоминал
Информация, знания, данные… Это очень интересная тема. Думаю заслуживает отдельного поста. Как нибудь соберусь с силами и напишу. Там и продолжим обсуждение.
Это, как раз, и есть прикладное программирование, о котором я писал в своем посте. Более того я утверждал, что за системами, подобными CAD, — будущее.
Еще раз, космический аппарат, двигаясь в гравитационном поле, никому никаких сообщений не посылает и не принимает. И его имитационные модели, кстати, тоже.
«Бросая в воду камешки, смотри на круги, ими образуемые...» ( (с) Козьма Прутков) — это тоже про обмен информацией?
А, ничего что, Шеннон писал применительно к техническим системам, лишь о сигналах и связи, да еще при этом сам указывал, что информация, которая передается этими сигналами, его не интересует. А ты говоришь, что он ее определял.
Какая связь краш-теста и определения информации по Шеннону? И почему определение, например, не по Винеру?