Здравствуйте, gandjustas, Вы писали:
G>Это какой-то неправильный метод, ибо он по сути повышает риски. Если тебе по какой-то причине приходится писать больше и "дороже", то это никак не страхует тебя от последующего переписывания, даже наоборот. Правильный путь — писать меньше и "дешевле".
Уж какой есть, других работающих пока нет.
Те же военные и ракетчики не ленятся и две и больше независимо разработанных программ для особо критических мест писать и делать
перекрестную проверку. Что не мешает там же применять и формальную верификацию, которая для сколько не будь не тривиальных программ
очень сложна.
G>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". FR>>Очень даже коррелируют. G>Ты для начала формализуй понятие "сложности".
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
G>>Это какой-то неправильный метод, ибо он по сути повышает риски. Если тебе по какой-то причине приходится писать больше и "дороже", то это никак не страхует тебя от последующего переписывания, даже наоборот. Правильный путь — писать меньше и "дешевле".
FR>Уж какой есть, других работающих пока нет. FR>Те же военные и ракетчики не ленятся и две и больше независимо разработанных программ для особо критических мест писать и делать FR>перекрестную проверку. Что не мешает там же применять и формальную верификацию, которая для сколько не будь не тривиальных программ FR>очень сложна.
У них софт, который скорее "хард". Цена ошибки примерно такая же как у электронщиков, и методы соответствующие.
Кода делаешь программы для бизнеса, условия другие.
G>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". FR>>>Очень даже коррелируют. G>>Ты для начала формализуй понятие "сложности". FR>Тут уже был флейм на много страниц.
И без окончательного решения
Здравствуйте, IT, Вы писали:
IT>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.
Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто. Из этого, по-моему, скорее можно сделать вывод о том, что микроэлектроника — более сложная отрасль. Но не обязательно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, FR, Вы писали:
FR>Боюсь во втором не раньше чем научимся формализовать всю цивилизацию, так как IT по сути превращается в "нервы" этой цивилизации, как энергетика стала ее кровью.
А чем цивилизация отличается от ее отсутствия кроме формализованности?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sinix, Вы писали:
S>Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости.
Вообще-то 100% задач — это формализация бардака, потому как пока у нас нет формализованного описания — текста программы — автомат автоматизирующий бардак не скомпилируется и/или будет автоматизировать неправильно.
S>Перевоспитаете человечество — будет вам формализуемые и непротиворечивые бизнес-требования.
Если требования будут формализованы — места между формализованными требованиями и компилятором для программиста вовсе не останется. Точнее тот, кто формализует требования — это и есть программист. В этом его работа и заключается.
S>А теперь вы ставите лошадь позади телеги Ничего и никогда не разрабатывалось целенаправленно. Никто не изобретал именно сотовый телефон, просто существующие технологии применялись, чтобы наиболее эффективно покрыть потребность в общении на расстоянии. Фундаментальные исследования потому и фундаментальные, что нифига не известно, дадут ли они хоть какой-то выхлоп и в какой стороне аукнется.
А какое отношение пилотируемая экспедиция на Марс имеет к фундаментальным исследованиям? Да даже экспериментальная планетология получит от беспилотных зондов за те же деньги полезный выхлоп на три порядка больше. Польза от экспедиции будет только в отработке технологий, которые до нее были не нужны, ядерных лампочек, каких нибудь. Я о том и говорю, потребность в общении на расстоянии двигала развитие соотвествующих технологий. Потребности в полете на Марс практически нет, а все необходимые для такого полета фундаментальные исследования уже проделаны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
K>А чем цивилизация отличается от ее отсутствия кроме формализованности?
Это далеко не та формализация которая требуется вычислительным устройствам.
Отличается все-таки не степенью формализации (это скорее следствие) а степенью
организованности и способностью устойчиво и долговременно поддерживать эту
организованность.
Здравствуйте, Klapaucius, Вы писали:
S>>Я ещё раз повторюсь. 99% задач — автоматизация бардака с очень большой долей неопределённости. K>Если требования будут формализованы — места между формализованными требованиями и компилятором для программиста вовсе не останется. Точнее тот, кто формализует требования — это и есть программист. В этом его работа и заключается.
Вы неисправимы Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака. Соответственно, требования и пожелания к системе — малопредсказуемы и зачастую необъективны. Да, мы можем отсечь всю дурь и написать сферокод, идеальный в своей законченной бесполезности. Или смириться с тем, что _мы не знаем_ что нужно от системы, и удастся ли это реализовать и делать то, что возможно, и переделывать при очередном "усё пропало".
Я в этой ветке закруглюсь — всё что хотел высказал, по кругу ходить не хоцца. Спасибо!
Здравствуйте, FR, Вы писали:
K>>А чем цивилизация отличается от ее отсутствия кроме формализованности? FR>Это далеко не та формализация которая требуется вычислительным устройствам.
Если бы она была в точности та — работа программиста была бы ненужной.
FR>Отличается все-таки не степенью формализации (это скорее следствие) а степенью FR>организованности и способностью устойчиво и долговременно поддерживать эту FR>организованность.
Да, все верно. И по мере того, как IT будет "превращаться в "нервы" этой цивилизации", придется IT от детских болезней избавляться. Как раз в интересах поддержания организованности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sinix, Вы писали:
S>Вы неисправимы Любая программа, увы, работает не в вакууме, её конечная цель — автоматизация действий заказчика — того самого бардака. Соответственно, требования и пожелания к системе — малопредсказуемы и зачастую необъективны. Да, мы можем отсечь всю дурь и написать сферокод, идеальный в своей законченной бесполезности.
Тут явное недопонимание. Я совершенно не считаю, что нужно писать какой-то там сферокод, да еще и идеальный в своей законченности. Я вообще не люблю делать что-то бесполезное — мне лень. Требования вообще субъективны. Требования к чему угодно. Потому, что требования выставляю люди. Смысл научных и инженерных методов не в том, чтобы отсечь дурь, потому что тогда ничего уже не останется. А разложить дурь по полочкам, отогнать из нее смысл. И желательно проделывать это в промышленных масштабах. Смысл приходится извлекать из дури, а порядок делать из бардака потому, что больше не из чего.
S>Или смириться с тем, что _мы не знаем_ что нужно от системы, и удастся ли это реализовать и делать то, что возможно, и переделывать при очередном "усё пропало".
Не нужно ни с чем смиряться. Нужно вооружиться познавательным оптимизмом, гибкой и современной методологией и отвоевывать землю упорядоченности у болота бардака. Потому, что без этого реализовать ничего не удасться. Это главное из того, что помогло человечеству чего-то достичь за последние два — три века после тысячелетий стагнации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
IT>>Тем, что программист гораздо чаще сталкивается с противоречивыми требованиями, чем микроэлектронщик.
K>Я думаю это потому, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману. Иначе микроэлектронщики сталкивались с такими же требованиями так же часто.
Совершенно верно.
K>Из этого, по-моему, скорее можно сделать вывод о том, что микроэлектроника — более сложная отрасль. Но не обязательно.
Нет. Из этого можно сделать вывод лишь о том, что тем, кто выдает требования электронщикам, противоречивые требования просто не по карману.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.
Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.
G>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска. G>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.
Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс.
G>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью".
Так не бывает. Факторы есть, а корреляции нет Есть вполне объективная сложность — сложность понимания решаемой задачи. В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Klapaucius, Вы писали:
K>Да, все верно. И по мере того, как IT будет "превращаться в "нервы" этой цивилизации", придется IT от детских болезней избавляться. Как раз в интересах поддержания организованности.
Боюсь, не всё так просто. В сравнении с другими инжинерными дисциплинами у IT есть пара принципиальных отличий:
— очень низкий порог вхождения для получения хоть какого-нибудь результата,
— воплощение идеи практически не требует никаких затрат, кроме умственных.
Эти два фактора кардинально расширяют диапозон применения IT решений. Настолько кардинально, что предыдущие опыты "поддержания организованности" и борьбы с детскими болезными работать просто не будут.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT> — очень низкий порог вхождения для получения хоть какого-нибудь результата, IT> — воплощение идеи практически не требует никаких затрат, кроме умственных. IT>Эти два фактора кардинально расширяют диапозон применения IT решений. Настолько кардинально, что предыдущие опыты "поддержания организованности" и борьбы с детскими болезными работать просто не будут.
В штучном производстве железяк щас к тому же идёт. Самодельщики уже брезгуют лазерным утюгом — подавай готовый набор или принт-сервис.
А "разработка" всякой требухи аля дешёвые плееры/наушники вообще почти вся превратилась в выбор чипа/корпуса из предложенных ОЕМом.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>Ну то что ты говоришь называется различной ценой ошибки. Если ошибка в требованиях, выявленная после запуска в производство, в минкроэлектронике это 100% провал, то в софтостроении можно исправить, хоть и с большими трудозатратами.
IT>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы.
Кому обязаны?
Другое дело что не приступят электронщики к производству пока не будет достаточно формальных требований.
Максимум модели на компьютере гонять будут.
Да и как-то более принято использовать существующие компоненты, а не изобретать новые.
У программистов при этом:
1)Очень модно изобретать велосипеды
2)Очень модно использовать низкоуровневые средства
3)Совсем не модно использовать различные конструкторы и другие средства быстрого создания прототипов
4)Совсем не модно искать количественные характеристики программ и как-то работать с ними
Причем индустрия предлагает все это, но далеко не все хотят пользоваться.
G>>Инженеры-микроэлектронщики понимают цену такой ошибки и используют методы для максимального снижения риска. G>>Инженеры-программисты зачастую не понимают цену ошибки до того как она произойдет и соответствующих методов не применяют.
IT>Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс.
Очень повезло.
G>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". IT>Так не бывает. Факторы есть, а корреляции нет
Бывает.
IT>Есть вполне объективная сложность — сложность понимания решаемой задачи.
Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?
IT>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?
Хм... а что такое XP и Agile, если отбросить написание кода?
1)Частые поставки
2)Приемочные тесты
и собственно все...
Думаешь у электронщиков такого нет?
Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).
Здравствуйте, gandjustas, Вы писали:
G>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).
Угу вот только у нас готовые изделия по сути и являются средствами моделирования.
Здравствуйте, gandjustas, Вы писали:
IT>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы. G>Кому обязаны?
Здравому смыслу.
G>Другое дело что не приступят электронщики к производству пока не будет достаточно формальных требований. G>Максимум модели на компьютере гонять будут.
Точно. Да и вообще побольше постараются смоделировать.
G>Да и как-то более принято использовать существующие компоненты, а не изобретать новые.
Принято по тем же самым причинам.
G>У программистов при этом: G>1)Очень модно изобретать велосипеды
Потому что велосипеды каждый раз нужны с чуть более другими характеристиками.
G>2)Очень модно использовать низкоуровневые средства
Не знаю где это модно.
G>3)Совсем не модно использовать различные конструкторы и другие средства быстрого создания прототипов
Конструкторы используются постоянно и повсеместно. По-крайней мере System.String никто для себя без особой надобности не пишет. А средства быстрого создания прототипов вообще не понятно что такое.
G>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними
А где это модно?
G>Причем индустрия предлагает все это, но далеко не все хотят пользоваться.
Раз не хотят, значит им не нужно.
IT>>Всё они понимают. В нашей команде, например, на этом понимании построена архитектура приложений и весь тех. процесс. G>Очень повезло.
Не повезло, а образ мышления.
G>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". IT>>Так не бывает. Факторы есть, а корреляции нет G>Бывает.
Не бывает. Законы сохранения, точнее закон равновесия, не обманешь.
IT>>Есть вполне объективная сложность — сложность понимания решаемой задачи. G>Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?
Думаю что присутствует. Вопрос только в какой степени. Например, в программировании мы порой закладываем неопределённость требований в код, и в дальнейшем меняем работающее приложение под новые уточнённые требования. Такая сложность у электронщиков присутствует?
IT>>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков? G>Хм... а что такое XP и Agile, если отбросить написание кода? G>1)Частые поставки G>2)Приемочные тесты G>и собственно все... G>Думаешь у электронщиков такого нет? G>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные).
И какой из этого следует вывод?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Не важно как это называется. Важно, что в электронике требования обязаны быть более чётко формализированы. G>>Кому обязаны? IT>Здравому смыслу.
А чем разработка ПО хуже? Там меньше здравого смысла?
G>>Другое дело что не приступят электронщики к производству пока не будет достаточно формальных требований. G>>Максимум модели на компьютере гонять будут. IT>Точно. Да и вообще побольше постараются смоделировать.
G>>Да и как-то более принято использовать существующие компоненты, а не изобретать новые. IT>Принято по тем же самым причинам.
G>>У программистов при этом: G>>1)Очень модно изобретать велосипеды IT>Потому что велосипеды каждый раз нужны с чуть более другими характеристиками.
Наверное считают что нужны велосипеды с другими характеристиками.
G>>2)Очень модно использовать низкоуровневые средства IT>Не знаю где это модно.
Как-будто форум не читаешь.
G>>4)Совсем не модно искать количественные характеристики программ и как-то работать с ними IT>А где это модно?
Нигде, в том проблема.
G>>Причем индустрия предлагает все это, но далеко не все хотят пользоваться. IT>Раз не хотят, значит им не нужно.
G>>>>Есть еще факторы, но все они никак не коррелируют с какой-либо "сложностью". IT>>>Так не бывает. Факторы есть, а корреляции нет G>>Бывает. IT>Не бывает. Законы сохранения, точнее закон равновесия, не обманешь.
Равновесия и сохранения чего?
Ты же сам был против формализации понятия "сложности".
IT>>>Есть вполне объективная сложность — сложность понимания решаемой задачи. G>>Думаешь таковая сложность не присутствует у электронщиков? Или у любых других инженеров?
IT>Думаю что присутствует. Вопрос только в какой степени. Например, в программировании мы порой закладываем неопределённость требований в код, и в дальнейшем меняем работающее приложение под новые уточнённые требования. Такая сложность у электронщиков присутствует?
Конечно, зачастую сложность выносят на уровень прошивки, её поменять легче. Кроме того зачастую присутствует неопределенность в том окружении где будет работать изделие.
IT>>>В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков? G>>Хм... а что такое XP и Agile, если отбросить написание кода? G>>1)Частые поставки G>>2)Приемочные тесты G>>и собственно все... G>>Думаешь у электронщиков такого нет? G>>Только для "частых поставок" используются не готовые изделия, а средства моделирования (чуть более чем все — компьютерные). IT>И какой из этого следует вывод?
Выводы сам делай, ты же доказывал что инженерия в минкроэлектронике сильно отличается от программирования.
Здравствуйте, gandjustas, Вы писали:
IT>>Думаю что присутствует. Вопрос только в какой степени. Например, в программировании мы порой закладываем неопределённость требований в код, и в дальнейшем меняем работающее приложение под новые уточнённые требования. Такая сложность у электронщиков присутствует? G>Конечно, зачастую сложность выносят на уровень прошивки, её поменять легче. Кроме того зачастую присутствует неопределенность в том окружении где будет работать изделие.
Т.е. сваливают работу с неопределенностью на программистов.
Ничего и никогда не разрабатывалось целенаправленно. Никто не изобретал именно сотовый телефон, просто существующие технологии применялись, чтобы наиболее эффективно покрыть потребность в общении на расстоянии. Фундаментальные исследования потому и фундаментальные, что нифига не известно, дадут ли они хоть какой-то выхлоп и в какой стороне аукнется.
Если нам не помогут, то мы тоже никого не пощадим.
Есть вполне объективная сложность — сложность понимания решаемой задачи. В программировании для управления такой сложностью как раз в обсуждаемом контексте используются методологии из серии XP и Agile. Что-то подобное есть у электронщиков?
