Здравствуйте, gandjustas, Вы писали:
IT>>>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы. G>>>Кому обязаны? IT>>Здравому смыслу. G>А чем разработка ПО хуже? Там меньше здравого смысла?
Она не лучше и не хуже, она другая. И если в электронике никто в здравом уме не будет выпускать изделие, которое нужно будет допиливать в последствии, то в разработке ПО это сплошь и рядом. Впрочем я это уже говорил.
G>>>У программистов при этом: G>>>1)Очень модно изобретать велосипеды IT>>Потому что велосипеды каждый раз нужны с чуть более другими характеристиками. G>Наверное считают что нужны велосипеды с другими характеристиками.
Может быть и так. Главное им так удобнее. Думаю, если бы у электронщиков была возможность взять какую-нибудь опен-соурсную железяку, и допилить её сбоку под свои нужды, то они бы от такой возможности точно не отказались.
G>>>2)Очень модно использовать низкоуровневые средства IT>>Не знаю где это модно. G>Как-будто форум не читаешь.
Ну так просвети.
G>>>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними IT>>А где это модно? G>Нигде, в том проблема.
Значит никому не нужно
G>>>Причем индустрия предлагает все это, но далеко не все хотят пользоваться. IT>>Раз не хотят, значит им не нужно. G>
Что смешного?
G>>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". IT>>>>Так не бывает. Факторы есть, а корреляции нет G>>>Бывает. IT>>Не бывает. Законы сохранения, точнее закон равновесия, не обманешь. G>Равновесия и сохранения чего?
Сохранения сложности, чего же ещё.
G>Ты же сам был против формализации понятия "сложности".
А где я за?
IT>>Думаю что присутствует. Вопрос только в какой степени. Например, в программировании мы порой закладываем неопределённость требований в код, и в дальнейшем меняем работающее приложение под новые уточнённые требования. Такая сложность у электронщиков присутствует? G>Конечно, зачастую сложность выносят на уровень прошивки, её поменять легче. Кроме того зачастую присутствует неопределенность в том окружении где будет работать изделие.
Неопределённость окружения — это конечно здорово. Только вряд ли она выходит за рамки, определённые ТТХ самого изделия.
IT>>И какой из этого следует вывод? G>Выводы сам делай, ты же доказывал что инженерия в минкроэлектронике сильно отличается от программирования.
В определённом смысле, конечно, отличается и странно, что ты не можешь увидеть эти различия. Ну давай вот такой пример.
Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа. Так или иначе это понимают все, включая заказчиков ПО. Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная. Бизнесу гораздо проще примерять на себя полуготовый сюртук и заканчивать его внося корректировки по ходу дела. Всё это выглядит примерно вот так, но, если это работает, то кого это волнует. Лишь бы те, кто строит такое ПО сами понимали, что они делают и как и поменьше бы сравнивали себя с электронщиками и другой инженерией.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа.
Ну так с этого вроде и начали. Причем ты говорил что разработка ПО несет большую сложность. А получается наоборот.
IT>Так или иначе это понимают все, включая заказчиков ПО.
Ровно обратную ситуацию наблюдаю.
IT>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная.
Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.
Здравствуйте, gandjustas, Вы писали:
IT>>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа. G>Ну так с этого вроде и начали. Причем ты говорил что разработка ПО несет большую сложность. А получается наоборот.
Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно?
IT>>Так или иначе это понимают все, включая заказчиков ПО. G>Ровно обратную ситуацию наблюдаю.
Не повезло.
IT>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная. G>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков.
Какая разница чья это позиция? Ситуация типичная.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Когда у Тойты Королы возникают проблемы с тормозами, то производитель, чтобы пофиксить эту проблему, вынужден отозвать все машины и терпит при этом колоссальные убытки. Когда проблема возникает в Microsoft Windows 7, то Microsoft тупо выпускает очередной пач и фиксит все имеющиеся в мире экземпляры Windows 7 без каких-либо существенных потерь. О чём это говорит? Лично мне это говорит о том, что цена ошибки и модификации уже работающего ПО мизирна в сравнении с ошибками в и модификацией уже работающего железа. G>>Ну так с этого вроде и начали. Причем ты говорил что разработка ПО несет большую сложность. А получается наоборот.
IT>Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно?
Вот уже интереснее. Можешь формализовать как "не навредить, не сломать, соответствующим образом построить архитектуру" и сколько это стоит?
IT>>>Так или иначе это понимают все, включая заказчиков ПО. G>>Ровно обратную ситуацию наблюдаю. IT>Не повезло.
"Ситуация типичная" (С)
IT>>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная. G>>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков. IT>Какая разница чья это позиция? Ситуация типичная.
Вообще говоря большая. Будучи ближе к "бизнесу" я начал по-другому подходить к разработке. Лишние уровни косвенности между заказчиком и разработчиком зачастую идут во вред разработке и создают довольно абсурдные ситуации.
Здравствуйте, FR, Вы писали:
Кэр>>Лично мне башню оторвало надолго серии, где показывали что такое на самом деле LINQ, что такое монады и как они тут рулят, как оно оборачивается в Rx, какие есть области применения. Я тут заобщался с Эриком Мейером (мега-дядька!) он утверждает и показывает, что Rx на самом деле решает проблему сложности параллельного программирования — я это хотел тут выложить и обсудить, просто руки еще не дошли.
FR>Это все было в 70-ых — 80ых годах.
Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?
Здравствуйте, gandjustas, Вы писали:
IT>>Наоборот — это для заказчика/клиента. А для программиста это думать о том, чтобы не навредить, не сломать, соответствующим образом построить архитектуру. Или ты думаешь всё это даётся бесплатно? G>Вот уже интереснее. Можешь формализовать как "не навредить, не сломать, соответствующим образом построить архитектуру" и сколько это стоит?
Зачем? Что ты с этой формализацией собираешься делать?
IT>>>>Поэтому, ситуация в программировании "- Жора! Жарьте рыбу. — Так рыбы нет! — Жора, вы жарьте! Рыба будет." обычная и я бы даже сказал типичная. G>>>Мне кажется ты путаешь позицию сейлзов\менеджеров и заказчиков. IT>>Какая разница чья это позиция? Ситуация типичная. G>Вообще говоря большая. Будучи ближе к "бизнесу" я начал по-другому подходить к разработке. Лишние уровни косвенности между заказчиком и разработчиком зачастую идут во вред разработке и создают довольно абсурдные ситуации.
Будучи ближе к бизнесу я понял что бизнесу вообще начхать на любые уровни не только косвенности, но и всего остального. Бизнесу нужен результат и больше ничего.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Кэр, Вы писали:
FR>>Это все было в 70-ых — 80ых годах.
Кэр>Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?
Концепции лежащие в их основе были чем-то новым эти самые 80 а не сейчас, и уже в конце 80 начале 90 воплотилось в таких языках как
Haskell и Clean.
Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака
Подскажите старику, игра Angry Birds для iPhone — какие действия и какого заказчика автоматизирует? Или это не "программа"? Или под "программой" вы понимаете что-то специфическое — если да, то что?
Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака
EOH>Подскажите старику, игра Angry Birds для iPhone — какие действия и какого заказчика автоматизирует? Или это не "программа"? Или под "программой" вы понимаете что-то специфическое — если да, то что?
В ветке вроде как говорят о разработке; подразумевалось заказное ПО. Можно было бы уточнить, казалось, что контекста очевидно.
И да, в игрострое бардак тоже присутствует; обусловлен практически тем же: необходимостью сделать успешный продукт самнезнаюкак. Только акцент смещён с "эффективно реализовать заранее неизвестные требюования" на "как-то отличиться от сотни клонов + понравиться игрокам".
В ветке вроде как говорят о разработке; подразумевалось заказное ПО.
Я прекрасно все понимаю, меня просто актуальная терминология интересует. Я правильно понимаю, что если программа "разрабатывается" — то это заказное ПО? И "заказное" тут подразумевается автоматизация бизнес-процессов, так как если я закажу, например, игрушку или коробочный продукт — то там не будет "автоматизации действий заказчика"?
В ветке вроде как говорят о разработке; подразумевалось заказное ПО.
EOH>Я прекрасно все понимаю, меня просто актуальная терминология интересует. Я правильно понимаю, что если программа "разрабатывается" — то это заказное ПО? И "заказное" тут подразумевается автоматизация бизнес-процессов, так как если я закажу, например, игрушку или коробочный продукт — то там не будет "автоматизации действий заказчика"?
. Всё последующее — мы начали с Эдисона и Теслы, а закончили тем, что все неправы.
В процитированном посте я отвечал на
Сложности не сопоставляются ... потому что в одном случае индустрия созрела и формализация применяется, а во втором случае индустрия несформирована и никто ничего и не пытается формализовать.
и пытался донести, что поскольку сама предметная область нечёткая, то и формироваться/формализоваться нечему.
Точнее, можно работать по принципу "что попросили — то и нате", с железной отмазкой "самдурак раз не можешь сказать чё те надо". В результате то же самое — срыв сроков, перерасход бюджета, программа не делает то, что нужно заказчику да ещё и кривая.
Ещё одна проблема: я неоднократно сталкивался с тем, что сам заказчик не понимает, чего он хочет и как работает автоматизируемая деятельность. Или предметная область слишком сложна и сама по себе непредсказуема. Или, самое печальное — зачастую люди не хотят разбираться и реагируют кране агрессивно на любые расспросы. У Брукса в "Design on Design" мне только вчера попалась подходящая цитата:
Then, slowly, I came to realize that the most useful service
I was performing for my client was helping him decide what he
really wanted.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Кэр, Вы писали:
FR>>>Это все было в 70-ых — 80ых годах.
Кэр>>Все остальное уже более-менее обсудили. Но вот это интересно. Что было в 70-80? Rx как LINQ поверх push based collections — это свеженький концепт. С новыми необычными применениями. Или вы можете показать, что это не так?
FR>Концепции лежащие в их основе были чем-то новым эти самые 80 а не сейчас, и уже в конце 80 начале 90 воплотилось в таких языках как FR>Haskell и Clean.
Ах концепции... Да и вообще архитектура процессора никак не поменялась, так что ничто не ново под луной, ага?
Ну и Эрик Мейер — это один их архитекторов Хаскела. Я ему верю больше, когда он говорит, что это новый концепт, чем вам
В процитированном посте я отвечал на ... и пытался донести, что поскольку сама предметная область нечёткая, то и формироваться/формализоваться нечему. Ещё одна проблема: я неоднократно сталкивался с тем, что сам заказчик не понимает, чего он хочет и как работает автоматизируемая деятельность. Или предметная область слишком сложна и сама по себе непредсказуема. Или, самое печальное — зачастую люди не хотят разбираться и реагируют кране агрессивно на любые расспросы.
В разработке ПО для автоматизации бизнес-процессов в целом можно сказать, что бардак по этому. Но ведь автоматизация бизнес-процессов — это не вся разработка ПО. И даже не половина. Вряд ли где есть точная статистика, но я сомневаюсь что всякие недо-1С, внутренниие вебстранички и прочие прослойки между складом и базой данных занимают очень большую нишу. Ведь есть еще разработка операционных систем, коробочное ПО, геймдев, драйвера, прошивки микроконтроллеров, веб сайты...
Что характерно — уровень бардака (чудовищный) примерно одинаков. И если про заказной сайт для автоматизации добавления заказа в базу данных можно все свалить на заказчика и постоянно меняющиеся требования — то что делать с остальными областями? У коробочных продуктов-то заказчика как такового нету. И требования там разработчик сам себе ставит. А код гниет точно также. И сроки срываются. И через раз все заново переписывается. И парк велосипедов как в парке Горького. И неподдерживаемое, неподдающееся рефакторингу спагетти точно так же пишут.
Здравствуйте, Eye of Hell, Вы писали:
EOH>Что характерно — уровень бардака (чудовищный) примерно одинаков. И если про заказной сайт для автоматизации добавления заказа в базу данных можно все свалить на заказчика и постоянно меняющиеся требования — то что делать с остальными областями? У коробочных продуктов-то заказчика как такового нету. И требования там разработчик сам себе ставит. А код гниет точно также. И сроки срываются. И через раз все заново переписывается. И парк велосипедов как в парке Горького. И неподдерживаемое, неподдающееся рефакторингу спагетти точно так же пишут.
EOH>Почему? Я не знаю .
Вы сами всё сказали
Я ещё в первом посте озвучил 2 основные причины:
1. Сложность задачи несопоставима с выделенными ресурсами.
Фактически, создавая ПО, мы пытаемся заставить _детерминированную_ машину заставить имитировать процессы _реального_ мира при минимальном участии человека. Там, где у нас сами процессы формализованы — круглое щастье.
Там, где нет — нет. В этом случае мы одновременно с разработкой ПО пытаемся изучить реальный мир (явно или неявно — неважно). Ключевая фраза — мы не знаем, что нам нужно делать. Даже с приблизительной определённостью. Точнее, можем узнать, но потребные ресурсы будут сопоставимы с затратами на создание действующей модели — ПО. Вот в этом и заключается вся сложность.
И подвижек тут не предвидится: если мы сделаем чугуневое ПО, нам придётся делегировать ответственность за неопределённость уровнем выше. В старых добрых 80х, когда люди ещё временами верили в разумность происходящего, была надежда на успех АРМ: дескать, машина нудятину возьмёт на себя, оставив человеку должность рулевого. Ничего не вышло по 3м причинам:
1.1. Работы меньше не становится. Если удастся частично разгрузить человека, на него неизбежно взвалят дополнительные обязанности. И да, копир с автоподатчиком может оказаться дороже оператора копировальной машины.
1.2. Там, где задача выходит за пределы возможностей одного человека, необходимо взаимодействовать. Насколько люди к этому способны (в долговременной перспективе, да ещё и в количестве большем трёх), думаю, объяснять не надо.
1.3. Человек — не машина: он не может постоянно и с должной эффективностью работать мозгом для АРМ. Увы, чтобы это обнаружить надо было дождаться, пока оператор ЭВМ не стал синонимом для распознавателя капч.
В сферическом и волшебном мире можно кое-что изменить. Надо всего-то отказаться от принципа "главное — сиюминутный результат, а там разберёмся"
2. Нет этапа производства/обкатки, с достаточным покрытием кода. Во-первых см причину 1. Во-вторых полноценно всё проверить нельзя из-за сложности системы. В-третьих, сама проверка экономически невыгодна: с ростом сложности затраты на поддержания качества растут чуть ли не по экспоненте.
Даже в винде (которую почему-то принято считать эталоном глюкокривости) на одного кодера приходится немало тестеров, технических писателей, локализаторов, тестеров, художников, дизайнеров UI, специалистов по юзабилити, архитекторов, тестеров и менеджеров. За точные цифры буду благодарен.
Кстати, где-то попадался великолепный англоязычный пост, в котором описывался объём затрат для попадания нескольких строчек API в релизный код. Никто ничего такого не помнит?
Здравствуйте, Кэр, Вы писали:
Кэр>Ах концепции... Да и вообще архитектура процессора никак не поменялась, так что ничто не ново под луной, ага?
Я же пишу было реализовано в 90-ых.
До этого без проблем работал как паттерн в ML образных.
Кэр>Ну и Эрик Мейер — это один их архитекторов Хаскела. Я ему верю больше, когда он говорит, что это новый концепт, чем вам
Ну не будет же он говорить что повторяет давно известное, и им же самим уже реализованное в другом языке, не по микросовтовски это
Здравствуйте, FR, Вы писали:
FR>Я же пишу было реализовано в 90-ых. FR>До этого без проблем работал как паттерн в ML образных.
Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.
FR>Ну не будет же он говорить что повторяет давно известное, и им же самим уже реализованное в другом языке, не по микросовтовски это
О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением.
Кэр>Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.
Затруднит Хаскеля к сожалению тогда еще не было.
Но реактивное программирование уже было:
FR>>Ну не будет же он говорить что повторяет давно известное, и им же самим уже реализованное в другом языке, не по микросовтовски это
Кэр>О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением.
Здравствуйте, FR, Вы писали:
Кэр>>Ну то есть вас не затруднит показать библиотеку-аналог Rx, например, в Хаскеле датированный 70-80 прошлого века? Или 90-х, бог с вами. Именно Rx, а не какую-то библиотеку со словом "монада" внутри.
FR>Затруднит Хаскеля к сожалению тогда еще не было. FR>Но реактивное программирование уже было: FR>http://www-sop.inria.fr/mimosa/rp/generalPresentation/index.html FR>
FR>The project, previously called RC project, has started in 1988
Извините, видимо это моя ошибка. Я указал, что нужно именно Rx как LINQ поверх push based collections — в этом вся соль. А потом сказал, что нужна не просто библиотека, где есть слово "монада". Забыл уточнить, что нужна не просто библиотека, которая тоже называется reactive Но как вы понимаете перечисление всех отрицаний может занять довольно долгое время.
А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.
FR>>>Ну не будет же он говорить что повторяет давно известное, и им же самим уже реализованное в другом языке, не по микросовтовски это Кэр>>О, срывают покровы! Это всегда интересно. Жду ответа с нетерпением. FR>Побольше побольше яду!
А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?
Кэр>Извините, видимо это моя ошибка. Я указал, что нужно именно Rx как LINQ поверх push based collections — в этом вся соль. А потом сказал, что нужна не просто библиотека, где есть слово "монада". Забыл уточнить, что нужна не просто библиотека, которая тоже называется reactive Но как вы понимаете перечисление всех отрицаний может занять довольно долгое время.
Да я понял пуговицы обязательно должны быть перламутровые, извините не учел-с
Кэр>А если серьезно, то все эти stop(), singal(), awaits(), merge() и прочее — это страх божий. И нифига это не тоже самое, как вы не вертите. Код на Rx получается гораздо более лаконичный и понятный.
В хаскелевских уже давно все в монады запаковано http://conal.net/fran/tutorial.htm
Удобные реактивные библиотеки совсем не новинка, даже питоновскому Trellis уже года три наверно.
Кэр>А вы ожидали, что яд — это только ваш скилл, другим совершенно недоступный? Вы не находите это несколько наивным?
Нет до вас мне далеко, так что не претендую, долго не смогу в таком тоне.
Если нам не помогут, то мы тоже никого не пощадим.
.
