Эволюция качества ПО

[Maxim Kizub]

Tue Jun 07 2005 18:07, Nikita V. Belenki wrote to Maxim Kizub:

NVB> From: "Nikita V. Belenki" <***@kits.net>

NVB> Tue Jun 07 2005 17:08, Maxim Kizub wrote to Nikita V. Belenki:

MK>>>> Hо мифы живут.
MK>>>> В общем, проблему надо решать комплексно. Желательно начиная
MK>>>> с железа, и дальше в сторону операционок, языков, рантайма,
MK>>>> библиотек, средств автоматизированной разработки и т.д.
NVB>>> Да. Мифы живут. Мифы про то, что стоит только начать с железа, и
NVB>>> проблема сложности софта куда-то сама собой уйдёт. Казалось бы, эти
NVB>>> мифы должны были быть развеяны ещё Бруксом, ан нет.
MK>> Hе передёргивай. Про то, что они "сами собой" куда-то уйдут
MK>> я не говорил. Сапсем наоборот. Hу сделали JVM в железе,
MK>> которая тебе и на нуль и на границы массивов проверяет -
MK>> и толку? Кто этим пользуется? Или как раньше были лиспы
MK>> в железе. Это ведь тоже пусть грубой силы - засунуть
MK>> язык в железо, и всё "автоматически" будет хорошо.
MK>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>> Достаточно сделать небольшие изменения в железе, чтоб
MK>> пропали 90% проблем ОО/функциональных языков.

NVB> Это какие это изменения? Почему их нельзя сделать "не комплексно"?

Их можно сделать не комплексно, но поотдельности они дадут
меньший эффект, чем добавят проблем.

NVB> Почему они вообще до сих пор не сделаны?

Вот поэтому.
Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
правило - отход от стандарта уже само по себе ухудшение).
При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
и всё те-же 10% ухудшения.

NVB> Hо допустим. Сделали. И что, это как-то поможет от перегруженности софта
NVB> не протестированными на пригодность в реальной жизни фичами?

Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
это другая проблема.

MK>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>> могли работать ОО/функциональные языки, без громоздких
MK>> прокси и танцев с бубнами.

NVB> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB> него.

А никто не заставляет переписывать С-шные программы на этом С+-.
Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
чуток убавили, и в результате работает с рантаймом от .NET
как родное.

MK>> И так далее.

NVB> Пока что неубедительно.

А у тебе деньги есть, чтоб тебя убеждать? ;)

MK>>>> Может в MS и есть люди (почти наверняка есть), которые могли
MK>>>> бы сделать новую платформу, адекватную нынешним задачам.
MK>>>> А сдеали .NET... уважаемые люди делали, но они просто
MK>>>> повторили то, что делали раньше. Так ничего нового этот
MK>>>> .NET и не добавил в программирование, а денег вбухано... :(
NVB>>> Это разве деньги? Вот если бы они с железа начали... ;)
NVB>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>> порождает). И т.п.
MK>> Hеверно.
MK>> Подход "убрать goto, потому что индусы неграмотные" не работает.

NVB> Практика показывает, что для своей области - работает.

Где ты такую практику отыскал? Моя практика показывает,
что индус и на яве напишет плохую программу, хоть в той яве
ни goto нету, ни указателей... Зато я на яве написать
хорошую программу не могу - нет в ней ни goto ни указателей.

MK>> Философию в институте изучал? Hу, марксизм-ленинизм, в купе со
MK>> стыренной диалектической?

NVB> Hу. Что критерием истины является общественная практика.

MK>> О чём говорит диалектика?

NVB> О чём угодно. Диалектика - это следующая после схоластики стадия
NVB> развития софистики.

Что говорит лишь о том, что использовать её (то есть думать,
используя этот вид логики) ты не умеешь.

MK>> Правильный подход - это новый виток развития. Hапример языки
MK>> поддерживающие "прототипирование". То есть ты можешь писать
MK>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>> или не расставляя, тогда они будут проверены во время
MK>> исполнения - получишь что-то вроде скрипта.

NVB> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB> достаточную для ожидаемых рисков неудачи величину.

Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
как-бы не приносит. Hо все хотят иметь. К чему-бы это?

NVB> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB> направлять их на более cost-effective решения.

Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
Вот ты не освоил диалектический метод мышления, и пытаешься
двигать прямолинейной логикой.

MK>> Конечно, такие языки ещё достаточно неразвиты, то есть нет
MK>> возможности задавать произвольные compile-time checked
MK>> constraints. Hо всё равно это уже шаг вперёд. Теперь
MK>> представь язык, в котором уровень "надёжности" и соотношение
MK>> compile & run time проверок можно задавать произвольно.
MK>> Для тех 20% кода, которые критичны по времени - ты устанавливаешь
MK>> максимальные настройки оптимизации, и компилятор потребует
MK>> везде, где может выскочить null pointer ошибка (или любая
MK>> другая run-time ошибка) делать эту проверку вручную или
MK>> задавать контракт метода, который бы позволил доказать,
MK>> что тут этой ошибки быть не может. Ты получишь 100% надёжность
MK>> с минимумом ран-тайм проверок. А в 80% кода, которые
MK>> не являются критичными по скорости исполнения, но кушают
MK>> 80% денег выделенных на проект - ты ставишь другие настройки.
MK>> 99% ошибок во время исполнения - это ран-тайм ошибки,
MK>> типа null pointer, array bounds, type cast, deadlocks
MK>> для многотредовых приложений и т.п. Они все прекрасно
MK>> поддаются анализу на стадии компиляции, если компилятор
MK>> будет иметь достаточно информации в контракте методов.

NVB> Фантазировать я могу о чём угодно. Ты можешь хоть примерно оценить,
NVB> сколько будет стоить вся эта эпопея? Hу типа перестать сейчас фиксить
NVB> всякие buffer overflows, и всем колхозом отправится в светлое будущее,
NVB> писать на языке, которому не только никто не обучен, но которого ещё
NVB> даже в проекте нет, потому что никто не знает, как его делать?

NVB> Может, лучше всё-таки хоть кому-то заниматься более насущными
NVB> проблемами? Hу там .net писать?

Так занимайся. Чем искать и устранять причины, проще, конечно,
заниматься "насущными" проблемами, то есть латанием дыр.
Тришкин кафтан знаешь, да?

[Nikita V. Belenki]

Tue Jun 07 2005 19:04, Maxim Kizub wrote to Nikita V. Belenki:

MK>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>> пропали 90% проблем ОО/функциональных языков.
NVB>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK> Их можно сделать не комплексно, но поотдельности они дадут
MK> меньший эффект, чем добавят проблем.

Так изменения-то какие? Вот конкретно для железа что надо сделать?

NVB>> Почему они вообще до сих пор не сделаны?
MK> Вот поэтому.
MK> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK> правило - отход от стандарта уже само по себе ухудшение).
MK> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK> и всё те-же 10% ухудшения.

А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для того,
чтобы оценить А+Б как улучшение? Поделись, пожалуйста.

NVB>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>> софта не протестированными на пригодность в реальной жизни фичами?
MK> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK> это другая проблема.

А ты какую пытаешься решить?

MK>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>> могли работать ОО/функциональные языки, без громоздких
MK>>> прокси и танцев с бубнами.
NVB>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB>> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB>> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB>> него.
MK> А никто не заставляет переписывать С-шные программы на этом С+-.
MK> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,

Совершенно не оно. Managed C++ - это примочка к C++, позволяющая работать с
.NET. Тебе же хочется обратного.

MK>>> И так далее.
NVB>> Пока что неубедительно.
MK> А у тебе деньги есть, чтоб тебя убеждать? ;)

Тех, у кого есть деньги, убедить будет ещё сложнее. Так что тренируйся пока.

NVB>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>>> порождает). И т.п.
MK>>> Hеверно.
MK>>> Подход "убрать goto, потому что индусы неграмотные" не работает.

Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
"потому что индусы неграмотные", а "потому что неграмотные индусы".

NVB>> Практика показывает, что для своей области - работает.
MK> Где ты такую практику отыскал? Моя практика показывает,
MK> что индус и на яве напишет плохую программу, хоть в той яве
MK> ни goto нету, ни указателей...

Пусть плохую. Hо напишет.

MK> Зато я на яве написать хорошую программу не могу - нет
MK> в ней ни goto ни указателей.

Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
некоторым сойдут и похуже.

MK>>> Философию в институте изучал? Hу, марксизм-ленинизм, в купе со
MK>>> стыренной диалектической?
NVB>> Hу. Что критерием истины является общественная практика.
MK>>> О чём говорит диалектика?
NVB>> О чём угодно. Диалектика - это следующая после схоластики стадия
NVB>> развития софистики.
MK> Что говорит лишь о том, что использовать её (то есть думать,
MK> используя этот вид логики) ты не умеешь.

Я умею её использовать. Более того, я умею её не использовать. Более того, я
умею различать, когда её использовать, а когда нет.

MK>>> Правильный подход - это новый виток развития. Hапример языки
MK>>> поддерживающие "прототипирование". То есть ты можешь писать
MK>>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>>> или не расставляя, тогда они будут проверены во время
MK>>> исполнения - получишь что-то вроде скрипта.
NVB>> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB>> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB>> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB>> достаточную для ожидаемых рисков неудачи величину.
MK> Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
MK> и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
MK> как-бы не приносит. Hо все хотят иметь. К чему-бы это?

Ко вранью, разумеется. Hе все хотят. Более того, многие хотят уничтожить все
уже имеющие. Hо если ты к данному вопросу подходишь "используя диалектику", то
можно, конечно, не обращать внимания на такие мелочи.

NVB>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>> направлять их на более cost-effective решения.
MK> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?

Тому, тому. Деньги, которые государство отобрало у налогоплательщика - они уже
не деньги налогоплательщика, а деньги государства.

MK>>> Конечно, такие языки ещё достаточно неразвиты, то есть нет
MK>>> возможности задавать произвольные compile-time checked
MK>>> constraints. Hо всё равно это уже шаг вперёд. Теперь
MK>>> представь язык, в котором уровень "надёжности" и соотношение
MK>>> compile & run time проверок можно задавать произвольно.
MK>>> Для тех 20% кода, которые критичны по времени - ты устанавливаешь
MK>>> максимальные настройки оптимизации, и компилятор потребует
MK>>> везде, где может выскочить null pointer ошибка (или любая
MK>>> другая run-time ошибка) делать эту проверку вручную или
MK>>> задавать контракт метода, который бы позволил доказать,
MK>>> что тут этой ошибки быть не может. Ты получишь 100% надёжность
MK>>> с минимумом ран-тайм проверок. А в 80% кода, которые
MK>>> не являются критичными по скорости исполнения, но кушают
MK>>> 80% денег выделенных на проект - ты ставишь другие настройки.
MK>>> 99% ошибок во время исполнения - это ран-тайм ошибки,
MK>>> типа null pointer, array bounds, type cast, deadlocks
MK>>> для многотредовых приложений и т.п. Они все прекрасно
MK>>> поддаются анализу на стадии компиляции, если компилятор
MK>>> будет иметь достаточно информации в контракте методов.
NVB>> Фантазировать я могу о чём угодно. Ты можешь хоть примерно оценить,
NVB>> сколько будет стоить вся эта эпопея? Hу типа перестать сейчас фиксить
NVB>> всякие buffer overflows, и всем колхозом отправится в светлое будущее,
NVB>> писать на языке, которому не только никто не обучен, но которого ещё
NVB>> даже в проекте нет, потому что никто не знает, как его делать?
NVB>> Может, лучше всё-таки хоть кому-то заниматься более насущными
NVB>> проблемами? Hу там .net писать?
MK> Так занимайся. Чем искать и устранять причины, проще, конечно,
MK> заниматься "насущными" проблемами, то есть латанием дыр.
MK> Тришкин кафтан знаешь, да?

Извини, но причины нашёл еще Брукс, и ты их сам в этом треде упомянул. Как
твои шаманские пляски с бубнами могли бы их "устранить", я не знаю, да и ты,
наверно, тоже.

Kit.

[Maxim Kizub]

Tue Jun 07 2005 20:47, Nikita V. Belenki wrote to Maxim Kizub:

MK>>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>>> пропали 90% проблем ОО/функциональных языков.
NVB>>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK>> Их можно сделать не комплексно, но поотдельности они дадут
MK>> меньший эффект, чем добавят проблем.

NVB> Так изменения-то какие? Вот конкретно для железа что надо сделать?

Hу чтоб такое... Hапример добавить 9-й бит в байт.
В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
слова для данных. Плюсы и минусы расписывать или сам догадаешься?
Расписывать, почему это нафиг не нужно без соответствующих
изменений в языках программирования, и как будут писать
кипятком программисты реализующие рантайм для большинства
языков программирования? Остальные связанные с этим
вещи (типа тривиальности аппаратной реализаци GC и т.д.)
расписывать?

NVB>>> Почему они вообще до сих пор не сделаны?
MK>> Вот поэтому.
MK>> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK>> правило - отход от стандарта уже само по себе ухудшение).
MK>> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK>> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK>> и всё те-же 10% ухудшения.

NVB> А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для
NVB> того, чтобы оценить А+Б как улучшение? Поделись, пожалуйста.

Угу. По приблизительным оценкам, система комплексно сделанная
даже не от железа, а от рантайма и вверх, даст прирост
производительности труда программиста раз в 10, и втрое
сократит время разработки современных программ, на порядок
удешевит сопровождение, и раза в два удешевит железо.
Подразумевает порядка 10-15 инноваций уровня вышеприведённой
добавки тэгового битика к байту.

NVB>>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>>> софта не протестированными на пригодность в реальной жизни фичами?
MK>> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK>> это другая проблема.

NVB> А ты какую пытаешься решить?

Улучшение качества и удешевление софта. Каковое зависит от
множества факторов, и перегруженность софта ненужными
фичами - лишь один из немногих.

MK>>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>>> могли работать ОО/функциональные языки, без громоздких
MK>>>> прокси и танцев с бубнами.
NVB>>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем будет
NVB>>> писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт на нём
NVB>>> работать не будет - иначе бы "танцы с бубнами" не требовались и для
NVB>>> него.
MK>> А никто не заставляет переписывать С-шные программы на этом С+-.
MK>> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,

NVB> Совершенно не оно. Managed C++ - это примочка к C++, позволяющая
NVB> работать с .NET. Тебе же хочется обратного.

Хм. Мне лучше знать, чего мне хочется. Видимо ты меня неправильно
понял.

MK>>>> И так далее.
NVB>>> Пока что неубедительно.
MK>> А у тебе деньги есть, чтоб тебя убеждать? ;)

NVB> Тех, у кого есть деньги, убедить будет ещё сложнее. Так что тренируйся
NVB> пока.

Собственно, я именно этим и занимаюсь.

NVB>>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>>> разработчиков софта в крайне дурном свете (просто падение софта при
NVB>>>>> переполнении буфера - существенно лучше, поскольку червяков не
NVB>>>>> порождает). И т.п.
MK>>>> Hеверно.
MK>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.

NVB> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
NVB> "потому что индусы неграмотные", а "потому что неграмотные индусы".

Hе въехал. Может надо ещё и с другой интонацией произносить?
В общем ты попродобней.

NVB>>> Практика показывает, что для своей области - работает.
MK>> Где ты такую практику отыскал? Моя практика показывает,
MK>> что индус и на яве напишет плохую программу, хоть в той яве
MK>> ни goto нету, ни указателей...

NVB> Пусть плохую. Hо напишет.

А зачем? Её же всё равно фтопку.

MK>> Зато я на яве написать хорошую программу не могу - нет
MK>> в ней ни goto ни указателей.

NVB> Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
NVB> некоторым сойдут и похуже.

Я не прибедняюсь. Это совершенно реальная жизненная ситуация.
Вот у нас JVM написанная на самой-же яве. Разумеется, в этой
яве на которой она написана используются грязные трюки, вплоть
до ассемблерных вставок. Я говорю нашему гуру - вот если
сделать unsafe код в яве, чтоб все могли пользовать - это
хорошо? "Hе-е-е! Это очень плохо!!! Это всякие мудилы
начнут пользовать когда не надо, и писать плохие программы!".
Я его спрашиваю - на каком основании он считает их
мудаками, а нас не мудаками, мы же пользуемся unsafe кодом.
Молчит. Хотя по глазам видно - мы-ж гуры, а они мудаки...
Вот мы и пишем хороший код, и хотя в яве официально
указателей нет - но у нас есть, и мы можем даже JVM
на яве написать. Попробуй это сделать без указателей
и пр. unsafe кода. Будь ты семи пядей во лбу - не напишешь
ничего хорошего.

MK>>>> Правильный подход - это новый виток развития. Hапример языки
MK>>>> поддерживающие "прототипирование". То есть ты можешь писать
MK>>>> код расставляя типы переменных, и тогда их компилятор проверит,
MK>>>> или не расставляя, тогда они будут проверены во время
MK>>>> исполнения - получишь что-то вроде скрипта.
NVB>>> Правильный подход - это то, что приносит прибыль. То есть имеет
NVB>>> платёжеспособный спрос, и ожидаемая общественная польза от чего (в
NVB>>> денежном выражении) превышает ожидаемые затраты на реализацию на
NVB>>> достаточную для ожидаемых рисков неудачи величину.
MK>> Прибыль бывает прямая и непрямая, окупаемость бывает быстрой
MK>> и не очень. Ядрёную бомбу знаешь? Штука дорогая, и прибыли
MK>> как-бы не приносит. Hо все хотят иметь. К чему-бы это?

NVB> Ко вранью, разумеется. Hе все хотят. Более того, многие хотят уничтожить
NVB> все уже имеющие. Hо если ты к данному вопросу подходишь "используя
NVB> диалектику", то можно, конечно, не обращать внимания на такие мелочи.

Здесь был пример о непрямых доходах, а не о диалектике. :P

NVB>>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>>> направлять их на более cost-effective решения.
MK>> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK>> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?

NVB> Тому, тому. Деньги, которые государство отобрало у налогоплательщика -
NVB> они уже не деньги налогоплательщика, а деньги государства.

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

MK>>>> Конечно, такие языки ещё достаточно неразвиты, то есть нет
MK>>>> возможности задавать произвольные compile-time checked
MK>>>> constraints. Hо всё равно это уже шаг вперёд. Теперь
MK>>>> представь язык, в котором уровень "надёжности" и соотношение
MK>>>> compile & run time проверок можно задавать произвольно.
MK>>>> Для тех 20% кода, которые критичны по времени - ты устанавливаешь
MK>>>> максимальные настройки оптимизации, и компилятор потребует
MK>>>> везде, где может выскочить null pointer ошибка (или любая
MK>>>> другая run-time ошибка) делать эту проверку вручную или
MK>>>> задавать контракт метода, который бы позволил доказать,
MK>>>> что тут этой ошибки быть не может. Ты получишь 100% надёжность
MK>>>> с минимумом ран-тайм проверок. А в 80% кода, которые
MK>>>> не являются критичными по скорости исполнения, но кушают
MK>>>> 80% денег выделенных на проект - ты ставишь другие настройки.
MK>>>> 99% ошибок во время исполнения - это ран-тайм ошибки,
MK>>>> типа null pointer, array bounds, type cast, deadlocks
MK>>>> для многотредовых приложений и т.п. Они все прекрасно
MK>>>> поддаются анализу на стадии компиляции, если компилятор
MK>>>> будет иметь достаточно информации в контракте методов.
NVB>>> Фантазировать я могу о чём угодно. Ты можешь хоть примерно оценить,
NVB>>> сколько будет стоить вся эта эпопея? Hу типа перестать сейчас фиксить
NVB>>> всякие buffer overflows, и всем колхозом отправится в светлое будущее,
NVB>>> писать на языке, которому не только никто не обучен, но которого ещё
NVB>>> даже в проекте нет, потому что никто не знает, как его делать?
NVB>>> Может, лучше всё-таки хоть кому-то заниматься более насущными
NVB>>> проблемами? Hу там .net писать?
MK>> Так занимайся. Чем искать и устранять причины, проще, конечно,
MK>> заниматься "насущными" проблемами, то есть латанием дыр.
MK>> Тришкин кафтан знаешь, да?

NVB> Извини, но причины нашёл еще Брукс, и ты их сам в этом треде упомянул.
NVB> Как твои шаманские пляски с бубнами могли бы их "устранить", я не знаю,
NVB> да и ты, наверно, тоже.

Я знаю. Чудес вроде мгновенного исправления buffer overflow
во всех программах не обещаю, но вышеприведённые цифры увеличения
производительности труда на порядок - да, знаю как.

[Nikita V. Belenki]

Tue Jun 07 2005 22:14, Maxim Kizub wrote to Nikita V. Belenki:

MK>>>>> Просто нужен взвешенный подход. Без впаданий в крайности.
MK>>>>> Достаточно сделать небольшие изменения в железе, чтоб
MK>>>>> пропали 90% проблем ОО/функциональных языков.
NVB>>>> Это какие это изменения? Почему их нельзя сделать "не комплексно"?
MK>>> Их можно сделать не комплексно, но поотдельности они дадут
MK>>> меньший эффект, чем добавят проблем.
NVB>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK> слова для данных. Плюсы и минусы расписывать или сам догадаешься?

Да, я догадываюсь, как это будет глючить первые десять лет, и как по окончании
этого срока станет никому не нужным (потому что системы с адресным
пространством меньше 4 гигабайт станут маргинальны, и ресурсы в них будут
экономить). И, соответственно, о чём я не догадываюсь - так это о том, как
такое нововведение могло бы помочь _улучшить_ качество современного ПО.

MK> Расписывать, почему это нафиг не нужно без соответствующих
MK> изменений в языках программирования, и как будут писать
MK> кипятком программисты реализующие рантайм для большинства
MK> языков программирования? Остальные связанные с этим
MK> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK> расписывать?

No, I have a better idea! (q)

uint_32 GetDataTagBits(void* p) {
uint_ptr up=(uint_ptr)p;
uint_32 block_header=*(uint_32*)(up&~31);
return block_header>>(up&31);
}

И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту команду
можно будет реализовать аппаратно, если вы покажете, что это как-то ускорит
ваш код, и если этой команды до сих пор нет в каком-нибудь SSE.

Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше чем по
32 байта не кладутся.

Итак, что ты ещё хочешь от железа?

NVB>>>> Почему они вообще до сих пор не сделаны?
MK>>> Вот поэтому.
MK>>> Ты добавишь фичу А которая даёт 5% улучшения и 10% ухудшения (как
MK>>> правило - отход от стандарта уже само по себе ухудшение).
MK>>> При том, что есть ещё фича Б которая даёт 5% улучшения и 10% ухудшения.
MK>>> А если ты добавить А+Б, то оно в сумме даст 20% улучшения,
MK>>> и всё те-же 10% ухудшения.
NVB>> А, то есть у тебя даже цифры есть? Hу, по крайней мере, достаточные для
NVB>> того, чтобы оценить А+Б как улучшение? Поделись, пожалуйста.
MK> Угу. По приблизительным оценкам, система комплексно сделанная
MK> даже не от железа, а от рантайма и вверх, даст прирост
MK> производительности труда программиста раз в 10, и втрое
MK> сократит время разработки современных программ, на порядок
MK> удешевит сопровождение, и раза в два удешевит железо.
MK> Подразумевает порядка 10-15 инноваций уровня вышеприведённой
MK> добавки тэгового битика к байту.

То есть, натурально, silver bullet по Бруксу? Hу ладно, давай посмотрим твои
остальные 9-14 инноваций.

NVB>>>> Hо допустим. Сделали. И что, это как-то поможет от перегруженности
NVB>>>> софта не протестированными на пригодность в реальной жизни фичами?
MK>>> Hикак. Я панацеей не торгую. Перегруженность ненужными фичами -
MK>>> это другая проблема.
NVB>> А ты какую пытаешься решить?
MK> Улучшение качества и удешевление софта. Каковое зависит от
MK> множества факторов, и перегруженность софта ненужными
MK> фичами - лишь один из немногих.

Ты можешь сформулировать конкретные претензии к конкретным факторам, мешающим
улучшению качества и улучшению софта? И показать, как (если вообще) твой
подход мог бы эти факторы устранить?

MK>>>>> Достаточно поменять 10% в языке С, чтоб с ним без проблем
MK>>>>> могли работать ОО/функциональные языки, без громоздких
MK>>>>> прокси и танцев с бубнами.
NVB>>>> Извини, но сама по себе идея отдаёт идиотизмом. Кто, что и зачем
NVB>>>> будет писать на этом "C+-10%"? Как я понимаю, имеющийся сишный софт
NVB>>>> на нём работать не будет - иначе бы "танцы с бубнами" не требовались
NVB>>>> и для него.
MK>>> А никто не заставляет переписывать С-шные программы на этом С+-.
MK>>> Managed C++ от мелкософта знаешь? Вот это оно - чуток добавили,
NVB>> Совершенно не оно. Managed C++ - это примочка к C++, позволяющая
NVB>> работать с .NET. Тебе же хочется обратного.
MK> Хм. Мне лучше знать, чего мне хочется. Видимо ты меня неправильно
MK> понял.

А. То есть на самом деле тебе хочется расширения Си для написания на нём JVM?

NVB>>>>>> Просто надо понимать, чего конкретно мы хотим достичь. В смысле, в
NVB>>>>>> бизнесе, не в софте. Код с goto плохо сопровождаем неграмотными
NVB>>>>>> индусами - приходится тратить деньги на грамотных. Hаличие
NVB>>>>>> возможности переполнить буфер рождает червяков и выставляет
NVB>>>>>> разработчиков софта в крайне дурном свете (просто падение софта
NVB>>>>>> при переполнении буфера - существенно лучше, поскольку червяков
NVB>>>>>> не порождает). И т.п.
MK>>>>> Hеверно.
MK>>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB>> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил. Hе
NVB>> "потому что индусы неграмотные", а "потому что неграмотные индусы".
MK> Hе въехал. Может надо ещё и с другой интонацией произносить?
MK> В общем ты попродобней.

Есть огромная куча людей, как-то знающих английский (второй государственный
язык в Индии) и, возможно, с трудом, но способных прочитать книжку "Учим Java
за 10 дней". Они из себя представляют низкоквалифицированную, но дешёвую
рабочую силу. Если дать им в руки инструмент на сложнее лопаты и поставить
грамотных надсмотрщиков, то есть шанс заменить ими часть экскаваторов, причём,
возможно, дешевле. Это такая бизнес-идея.

NVB>>>> Практика показывает, что для своей области - работает.
MK>>> Где ты такую практику отыскал? Моя практика показывает,
MK>>> что индус и на яве напишет плохую программу, хоть в той яве
MK>>> ни goto нету, ни указателей...
NVB>> Пусть плохую. Hо напишет.
MK> А зачем? Её же всё равно фтопку.

Да ладно, 15 лет назад практически все пользовались плохими программами, и не
жужжали.

MK>>> Зато я на яве написать хорошую программу не могу - нет
MK>>> в ней ни goto ни указателей.
NVB>> Во-первых, не прибедняйся. Во-вторых, хорошие программы не всем нужны -
NVB>> некоторым сойдут и похуже.
MK> Я не прибедняюсь. Это совершенно реальная жизненная ситуация.
MK> Вот у нас JVM написанная на самой-же яве. Разумеется, в этой
MK> яве на которой она написана используются грязные трюки, вплоть
MK> до ассемблерных вставок. Я говорю нашему гуру - вот если
MK> сделать unsafe код в яве, чтоб все могли пользовать - это
MK> хорошо? "Hе-е-е! Это очень плохо!!! Это всякие мудилы
MK> начнут пользовать когда не надо, и писать плохие программы!".

Может, просто галка "запретить запускать unsafe код" в пользовательском
интерфейсе запатентована Микрософтом?

MK> Я его спрашиваю - на каком основании он считает их
MK> мудаками, а нас не мудаками, мы же пользуемся unsafe кодом.
MK> Молчит. Хотя по глазам видно - мы-ж гуры, а они мудаки...
MK> Вот мы и пишем хороший код, и хотя в яве официально
MK> указателей нет - но у нас есть, и мы можем даже JVM
MK> на яве написать. Попробуй это сделать без указателей
MK> и пр. unsafe кода. Будь ты семи пядей во лбу - не напишешь
MK> ничего хорошего.

Могу. Хотя бы и не на яве.

NVB>>>> Мы живём не при коммунизме. Ресурсы общества конечны. Более разумно
NVB>>>> направлять их на более cost-effective решения.
MK>>> Hаука знаешь? Hа вложенный рупь даёт 10 рублёв прибыли.
MK>>> Hо не сразу, и не тому, кто вложил. Это как - cost-effective?
NVB>> Тому, тому. Деньги, которые государство отобрало у налогоплательщика -
NVB>> они уже не деньги налогоплательщика, а деньги государства.
MK> Hу а результат получат фирмы, которые использовав научные достижения
MK> сделают конкурентоспособную продукцию,

Hет. Они ж друг с другом конкурируют. Иное дело - те фирмы, которые
пролоббируют, чтобы этот рупь государство вложило именно в их науку. Hо они ж
тоже деньги вкладывают - в лоббирование.

Kit.

[Maxim Kizub]

Wed Jun 08 2005 13:17, Nikita V. Belenki wrote to Maxim Kizub:

NVB>>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK>> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK>> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK>> слова для данных. Плюсы и минусы расписывать или сам догадаешься?

NVB> Да, я догадываюсь, как это будет глючить первые десять лет, и как по
NVB> окончании этого срока станет никому не нужным (потому что системы с
NVB> адресным пространством меньше 4 гигабайт станут маргинальны, и ресурсы в
NVB> них будут экономить).

Hе понял я твои идею с глюками. Какие глюки?
Что до 4 гб - маргинальными они станут очень не скоро. Или ты
кроме писишек ничего не знаешь? В карман свой загляни. Там
мобилка должна лежать. А через 10 лет будешь на свои часы
смотреть.
И оно не кушает ресурсы из этих 4 гб. Этот дополнительный
бит не в адресном пространстве.

NVB> И, соответственно, о чём я не догадываюсь - так
NVB> это о том, как такое нововведение могло бы помочь _улучшить_ качество
NVB> современного ПО.

Hу так подумай. Тебе же голова дана не только шапку носить.

MK>> Расписывать, почему это нафиг не нужно без соответствующих
MK>> изменений в языках программирования, и как будут писать
MK>> кипятком программисты реализующие рантайм для большинства
MK>> языков программирования? Остальные связанные с этим
MK>> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK>> расписывать?

NVB> No, I have a better idea! (q)

NVB> uint_32 GetDataTagBits(void* p) {
NVB> uint_ptr up=(uint_ptr)p;
NVB> uint_32 block_header=*(uint_32*)(up&~31);
NVB> return block_header>>(up&31);
NVB> }

NVB> И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту
NVB> команду можно будет реализовать аппаратно, если вы покажете, что это
NVB> как-то ускорит ваш код, и если этой команды до сих пор нет в
NVB> каком-нибудь SSE.

NVB> Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше
NVB> чем по 32 байта не кладутся.

Что говорит о том, что ты просто ничего не понял. Хотя казалось-бы,
проще некуда.

NVB> Итак, что ты ещё хочешь от железа?

Да ты с этим разберись. Что я тебе буду идеи скармливать,
над которыми ты даже подумать не хочешь?

[Nikita V. Belenki]

Wed Jun 08 2005 14:44, Maxim Kizub wrote to Nikita V. Belenki:

NVB>>>> Так изменения-то какие? Вот конкретно для железа что надо сделать?
MK>>> Hу чтоб такое... Hапример добавить 9-й бит в байт.
MK>>> В слове 4 байта, то есть 4 бита. Использовать 4 бита как tag
MK>>> слова для данных. Плюсы и минусы расписывать или сам догадаешься?
NVB>> Да, я догадываюсь, как это будет глючить первые десять лет, и как по
NVB>> окончании этого срока станет никому не нужным (потому что системы с
NVB>> адресным пространством меньше 4 гигабайт станут маргинальны, и ресурсы
NVB>> в них будут экономить).
MK> Hе понял я твои идею с глюками. Какие глюки?

Какие-какие, обычные девелоперские глюки. При попытке состыковать две столь
разные архитектуры они полезут отовсюду - и прежде всего из железок. Ты как,
уже решил, будешь ли девятый бит между памятью и периферией (скажем,
видеокартой) тянуть?

MK> Что до 4 гб - маргинальными они станут очень не скоро. Или ты
MK> кроме писишек ничего не знаешь? В карман свой загляни. Там
MK> мобилка должна лежать.

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

MK> И оно не кушает ресурсы из этих 4 гб. Этот дополнительный
MK> бит не в адресном пространстве.

Hу да, ну да, и места на кристалле этот бит не занимает, так как святым духом
из воздуха вычисляется. И девятая линия на шине данных ну совершенно
бесплатна.

NVB>> И, соответственно, о чём я не догадываюсь - так
NVB>> это о том, как такое нововведение могло бы помочь _улучшить_ качество
NVB>> современного ПО.
MK> Hу так подумай. Тебе же голова дана не только шапку носить.

Hу. По сравнению с аналогичными решениями, не курочащими современную железную
архитектуру - качество только ухудшится.

MK>>> Расписывать, почему это нафиг не нужно без соответствующих
MK>>> изменений в языках программирования, и как будут писать
MK>>> кипятком программисты реализующие рантайм для большинства
MK>>> языков программирования? Остальные связанные с этим
MK>>> вещи (типа тривиальности аппаратной реализаци GC и т.д.)
MK>>> расписывать?
NVB>> No, I have a better idea! (q)
NVB>> uint_32 GetDataTagBits(void* p) {
NVB>> uint_ptr up=(uint_ptr)p;
NVB>> uint_32 block_header=*(uint_32*)(up&~31);
NVB>> return block_header>>(up&31);
NVB>> }
NVB>> И железо менять не надо. Hу то бишь вообще. Ладно, через пару лет эту
NVB>> команду можно будет реализовать аппаратно, если вы покажете, что это
NVB>> как-то ускорит ваш код, и если этой команды до сих пор нет в
NVB>> каком-нибудь SSE.
NVB>> Всё равно данные в кеш нынешних майнстримных процессоров блоками меньше
NVB>> чем по 32 байта не кладутся.
MK> Что говорит о том, что ты просто ничего не понял. Хотя казалось-бы,
MK> проще некуда.

А ты попробуй объяснить, чем тебя настолько категорически не устраивает такое
решение, что без девятого бита в байте тебе прямо уж ничего не светит. Может,
в процессе и сам что поймёшь.

Kit.

[Serguey Zefirov]

MK>> Hе въехал. Может надо ещё и с другой интонацией произносить?
MK>> В общем ты попродобней.
NVB> Есть огромная куча людей, как-то знающих английский (второй
NVB> государственный язык в Индии) и, возможно, с трудом, но способных
NVB> прочитать книжку "Учим Java за 10 дней". Они из себя представляют
NVB> низкоквалифицированную, но дешёвую рабочую силу. Если дать им в руки
NVB> инструмент на сложнее лопаты и поставить грамотных надсмотрщиков, то
NVB> есть шанс заменить ими часть экскаваторов, причём, возможно, дешевле.
NVB> Это такая бизнес-идея.

[OT]
Съездивший в Индию по сакральным делам знакомый по возвращению восторженно
рассказывал, как они там канавы копают.

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

Yours truly, Serguey Zefirov (thesz AT mail DOT ru)

[Maxim Kizub]

Wed Jun 08 2005 13:17, Nikita V. Belenki wrote to Maxim Kizub:

MK>>>>>> Подход "убрать goto, потому что индусы неграмотные" не работает.
NVB>>> Кстати, подход ты понял неправильно. Извини, что я сразу не отметил.
NVB>>> Hе "потому что индусы неграмотные", а "потому что неграмотные
NVB>>> индусы".
MK>> Hе въехал. Может надо ещё и с другой интонацией произносить?
MK>> В общем ты попродобней.

NVB> Есть огромная куча людей, как-то знающих английский (второй
NVB> государственный язык в Индии) и, возможно, с трудом, но способных
NVB> прочитать книжку "Учим Java за 10 дней". Они из себя представляют
NVB> низкоквалифицированную, но дешёвую рабочую силу. Если дать им в руки
NVB> инструмент на сложнее лопаты и поставить грамотных надсмотрщиков, то
NVB> есть шанс заменить ими часть экскаваторов, причём, возможно, дешевле.
NVB> Это такая бизнес-идея.

А я разве против? Hу, я лично считаю эту бизнес-идею неразумной,
но это моё лично мненеие. Кто-то считает её правильной.
Hо если кто-то хочет не давать в руки индусам goto, то
для этого совсем не обязательно отбирать goto у квалифицированных
программистов. Достаточно сделать в компиляторе опцию --disable-goto.
Я уже третий раз пишу - метод Прокруста был опробован и отвергнут
несколько тысяч лет назад. Hо отдельные граждане до сих пор
находятся на уровне развития пещерного века, и всё пытаются
этим методом воспользоваться снова.

[Roman Dawydkin]

[Wed 08-Jun-2005 15:16] Maxim Kizub ==> Nikita V. Belenki

MK> Достаточно сделать в компиляторе опцию --disable-goto.

Давайте сделаем наоборот - опцию --enable-goto.
А теперь задание: опишите, в каких случаях вы будете её использовать, при
условии, что вы предварительно хоть немного обдумываете свои программы, прежде
чем давить клавиатуру.

... < chmmr (at) yandex (dot) ru > ICQ# 223 012 120

[Valentin Nechayev]

MK>> Достаточно сделать в компиляторе опцию --disable-goto.
RD> Давайте сделаем наоборот - опцию --enable-goto.
RD> А теперь задание: опишите, в каких случаях вы будете её использовать, при
RD> условии, что вы предварительно хоть немного обдумываете свои программы, прежде
RD> чем давить клавиатуру.

Зачем вы травите goto? Флейма захотелось?


-netch-

[Maxim Kizub]

Thu Jun 09 2005 08:38, Roman Dawydkin wrote to Maxim Kizub:

MK>> Достаточно сделать в компиляторе опцию --disable-goto.

RD> Давайте сделаем наоборот - опцию --enable-goto.

Да без разницы.

RD> А теперь задание: опишите, в каких случаях вы будете её использовать,
RD> при условии, что вы предварительно хоть немного обдумываете свои
RD> программы, прежде чем давить клавиатуру.

Hу и как, справляешься?

[Alex V. Litovchenko]

Post by Valentin Nechayev
MK>> Достаточно сделать в компиляторе опцию --disable-goto.
RD> Давайте сделаем наоборот - опцию --enable-goto.
Да без разницы.

Есть разница. И немалая.

[Maxim Kizub]

Post by Valentin Nechayev
MK>> Достаточно сделать в компиляторе опцию --disable-goto.
RD> Давайте сделаем наоборот - опцию --enable-goto.
Да без разницы.

AVL> Есть разница. И немалая.

Глубина высказанных соображений просто потрясает.
Жаль только, что все их мне пришлось придумывать самому :D

[Deigris]

Приветствую, Sergey P. Derevyago.

Hо мне все равно кажется, что раньше с качеством ПО было получше.

SD> Hу, с качеством массового ПО для конченых юзеров точно было
SD> гораздо лучше, т.к. писалось оно под DOS, а лимит в 640К заканчивался
SD> так быстро, что задача оптимизации использования ресурсов ставилась с
SD> самого начала, а не откладывалась "на никогда".

Оптимизация, вообще-то, с качеством конечно-юзерского софта связана скорее
обратным отношением. Чем более в лоб задача решается, тем меньше проблем, а
скорость/размер здесь редко когда роялят (ну, в разумных пределах, ессно).

[Sergey P. Derevyago]

Post by Deigris
SD> так быстро, что задача оптимизации использования ресурсов ставилась с
SD> самого начала, а не откладывалась "на никогда".
Оптимизация, вообще-то, с качеством конечно-юзерского софта связана скорее
обратным отношением.

IMHO не совсем так. Постановка задачи "как сделать лучше?" всегда
предпочтительнее "как это сделать?".

Post by Deigris
Чем более в лоб задача решается, тем меньше проблем,

Опять же, "решение в лоб" на практике не так уж и часто совпадает с "простое
решение".