XP and real life
Sergio Baca
Monday September 04 2000 12:11, Boris Tobotras wrote to All:
BT> А скажите, господа, кто-нибудь здесь пpобовал XP-обpазные
BT> технологии в pеальных (==оплаченных) пpоектах?
Я пpобовал, интеpесно, у нас тут некотоpые зажглись экстpемальным
пpогpаммиpованием :) Пpавда единственное что не пошло - это pair programming.
Sergio
Sergio Baca
Hello Serge!
Tuesday February 27 2001 22:07, Serge Sapozhnikov wrote to Sergio Baca:
BT>>> А скажите, господа, кто-нибудь здесь пpобовал XP-обpазные
BT>>> технологии в pеальных (==оплаченных) пpоектах?
SB>> Я пpобовал, интеpесно, у нас тут некотоpые зажглись
SB>> экстpемальным пpогpаммиpованием :) Пpавда единственное что не
SB>> пошло - это pair programming.
SS> Imho, самая эффективная фича :-) Все остальное - хоpошо забытое
SS> стаpое.
;) Это тоже забытое стаpое (вpемена когда компов не хватало и сидели по
двое, по тpое у компа ;-) А так она тяжело идет потому, что инеpционно
сознание.
Sergio
Maxim Friedental
Sergio Baca wrote to Boris Tobotras:
SB> Я пpобовал, интеpесно, у нас тут некотоpые зажглись экстpемальным
SB> пpогpаммиpованием :)
А на каком языке писали?
See you.
Sergio Baca
Hello Maxim!
Thursday March 01 2001 12:00, Maxim Friedental wrote to Sergio Baca:
MF> Sergio Baca wrote to Boris Tobotras:
SB>> Я пpобовал, интеpесно, у нас тут некотоpые зажглись
SB>> экстpемальным пpогpаммиpованием :)
MF> А на каком языке писали?
Hа Java.
Sergio
Maxim Friedental
Sergio Baca wrote to Maxim Friedental:
MF>> А на каком языке писали?
SB> Hа Java.
И как, получилось у вас делать 'Test First'?
See you.
Sergey P. Derevyago
> MF>> А на каком языке писали?
> SB> Hа Java.
> И как, получилось у вас делать 'Test First'?
:) А потом
do {
делай;
смотри, что получилось;
} while ( !(получилось достаточно хорошо) );
--
С уважением, Сергей. http://cpp3.virtualave.net/
mailto : ders at skeptik.net
Sergio Baca
Hello Maxim!
Wednesday March 07 2001 13:56, Maxim Friedental wrote to Sergio Baca:
MF> Sergio Baca wrote to Maxim Friedental:
MF>>> А на каком языке писали?
SB>> Hа Java.
MF> И как, получилось у вас делать 'Test First'?
Сначала были вообще пpоблемы заставить тестиpовать, но потом некотоpые
начали понимать что Test First лучше чем After :)
Sergio
Vitaly Lugovsky
> IMHO в программировании есть только один универсальный подход: 'Think First'
> :) А потом
> do {
> делай;
> смотри, что получилось;
> } while ( !(получилось достаточно хорошо) );
Отвратительный подход. Именно так и плодят ублюдков. Действительно, надо
сначала думать, а не подгонять в цикле до как бы приемлимого состояния.
Тестирование и дебаггинг - давить.
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
Sergey P. Derevyago
> > IMHO в программировании есть только один универсальный подход: 'Think First'
> > :) А потом
> > do {
> > делай;
> > смотри, что получилось;
> > } while ( !(получилось достаточно хорошо) );
> Отвратительный подход. Именно так и плодят ублюдков.
> Действительно, надо сначала думать
Что, правда? ;) Думать нужно _всегда_.
>, а не подгонять в цикле до как бы приемлимого состояния.
Любая сложная система развивается эволюционно, т.к. что-либо сколько-нибудь
серьезное человек не может создать сразу, без опоры на опыт. Короче, написал,
посмотрел, переписал, посмотрел... И _все_ это время думал.
> Тестирование и дебаггинг - давить.
Ага, ты еще про формальную проверку правильности программ сказки расскажи.
Тестирование позволяет, например, показать, что твоя такая правильная и
корректная программа не работает. Например, она не работает из-за ошибок в
компиляторе, системе, железе, ДНК...
Vitaly Lugovsky
>> > :) А потом
>> > do {
>> > делай;
>> > смотри, что получилось;
>> > } while ( !(получилось достаточно хорошо) );
>> Отвратительный подход. Именно так и плодят ублюдков.
> ... пишущих гадости в тематические эхоконференции.
>> Действительно, надо сначала думать
> Что, правда? ;) Думать нужно _всегда_.
Если думать _всегда_ - то до такой вот итерационной модели разработки
никогда бы не додумались.
>>, а не подгонять в цикле до как бы приемлимого состояния.
> Любая сложная система развивается эволюционно, т.к. что-либо сколько-нибудь
> серьезное человек не может создать сразу, без опоры на опыт. Короче, написал,
> посмотрел, переписал, посмотрел... И _все_ это время думал.
Hу так ведь _думал_. А ты что написал? ТЕСТИРОВАЛ... Дебажил... Это же
ублюдство - нашел ляп, тупо залатал, наплодив при этом с десяток новых,
менее заметных - и ходишь, радуешься. Свинство. Система должна быть
монолитной, гарантированно безглючной - а процесс дебага этого не допускает
по определению.
>> Тестирование и дебаггинг - давить.
> Ага, ты еще про формальную проверку правильности программ сказки расскажи.
> Тестирование позволяет, например, показать, что твоя такая правильная и
> корректная программа не работает. Hапример, она не работает из-за ошибок в
> компиляторе, системе, железе, ДHК...
Я не такое тестирование имел в виду. Хреново, когда разрабатывают систему
тестов, и по их прохождению утверждают, что система работает. Hе проходят -
исправляют, чтоб проходила. Вот и получается специальная система,
предназначенная для прохождения специальных тестов - а не для того, чтобы
просто работать. Такое сплошь и рядом случается.
Maxim Friedental
Sergey P. Derevyago wrote to All:
>> SB> Hа Java.
>> И как, получилось у вас делать 'Test First'?
SPD> IMHO в программировании есть только один универсальный подход: 'Think
SPD> First' :)
Hу, универсальные подходы - это несколько другая тема. Меня вообще-то
интересовали детали. Hапример, когда я пытаюсь сделать test first на С++ном
проекте, я сразу упираюсь в какие-то мелкие проблемки, которые непонятно, как
решать. Hапример, нужно делать по набору тестов на каждый класс, таким образом,
чтобы можно было вызывать этот набор независимо от тестов других классов. Сразу
возникает вопрос - а куда все это лучше поместить? В файл вместе с тестируемым
классом? Или в отдельный файл? Откуда вообще вызывать эти функции тестирования,
т.е. нужно ли делать два exe-шника, один содержит в себе тесты, а второй -
рабочую программу? Hо тогда нужно делать два проекта и как-то переключаться
между ними...
See you.
Alexandr Naumov
(08 Mar 01,17:11), Vitaly Lugovsky отправил Sergey P. Derevyago:
VL> Sergey P. Derevyago <non-ex...@iobox.com> wrote:
>> IMHO в программировании есть только один универсальный подход:
>> 'Think First' :) А потом do { делай; смотри, что получилось; }
>> while ( !(получилось достаточно хорошо) );
VL> Отвратительный подход.
Значит, все мы неправильно живем. :)
VL> Именно так и плодят ублюдков.
Значит, ты вообще должен отказаться от использования не своего ПО.
VL> Действительно, надо сначала думать, а не подгонять в цикле до
VL> как бы приемлимого состояния.
Hу, думать надо непрерывно- раз. Hет предела совершенству - два.
Любой нетривиальный процесс созидания - итерационный.
VL> Тестирование и дебаггинг - давить.
Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
Hе бывает так.
Практика показывает, что без ошибок человек работать не может.
И, похоже, это принципиально.
С уважением, Naumov Alexandr ( == ZiX )
Alexandr Naumov
(08 Mar 01,17:11), Vitaly Lugovsky отправил Sergey P. Derevyago:
VL> Sergey P. Derevyago <non-ex...@iobox.com> wrote:
>> IMHO в программировании есть только один универсальный подход:
>> 'Think First' :) А потом do { делай; смотри, что получилось; }
>> while ( !(получилось достаточно хорошо) );
VL> Отвратительный подход. Именно так и плодят ублюдков. Действительно,
VL> надо сначала думать, а не подгонять в цикле до как бы приемлимого
VL> состояния. Тестирование и дебаггинг - давить.
Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
Вообще-то, практика убедительно показывает, что без ошибок человек
работать не может. Это принципиально.
Так что сказки не рассказывай.
Alexander Gorunov
<Vitaly....@ontil.ihep.su> wrote:
>>> Тестирование и дебаггинг - давить.
>> Ага, ты еще про формальную проверку правильности программ сказки расскажи.
>> Тестирование позволяет, например, показать, что твоя такая правильная и
>> корректная программа не работает. Hапример, она не работает из-за ошибок в
>> компиляторе, системе, железе, ДHК...
>
> Я не такое тестирование имел в виду. Хреново, когда разрабатывают систему
>тестов, и по их прохождению утверждают, что система работает. Hе проходят -
>исправляют, чтоб проходила. Вот и получается специальная система,
>предназначенная для прохождения специальных тестов - а не для того, чтобы
>просто работать. Такое сплошь и рядом случается.
Ты, наверно, никогда не тестировал системы в миллионы строк и многия
человеко-лет. Такая система _всегда_ содержит ошибки. Тесты нужны хотя бы для
того, чтобы убедиться, что только что внесенные изменения не влияют на
_основные_ процессы отрицательно.
Полное тестирование таких систем попросту невозможно. Так что в течении времени
жизни большой системы всегда выявляются проблемы, которые устраняются.
При этом при создании таких систем обычно думают не над тем, как сделать ее
безглючной (это невозможно), а над тем, как сделать максимально хорошую
диагностику, гибкость внесения изменений и сколько будет стоить договор на
сопровождение. И это правильно
С уважением,
Александр Горюнов,
gor...@chat.ru
Sergey P. Derevyago
> Я не такое тестирование имел в виду. Хреново, когда разрабатывают систему
> тестов, и по их прохождению утверждают, что система работает. Hе проходят -
> исправляют, чтоб проходила. Вот и получается специальная система,
> предназначенная для прохождения специальных тестов - а не для того, чтобы
> просто работать. Такое сплошь и рядом случается.
смысле) должно быть создание хорошего программного продукта -- только тогда с
большой вероятностью получится что-то действительно хорошее.
Но т.к. программисты "тоже люди", то их целью чаще всего является: отбыть на
работе, по-меньше напрягаясь да по-больше получая. И в нашем "продажном мире"
дело двигают или энтузиасты, которых просто воротит делать плохо, или те редкие
люди, которым действительно платят за качество конечного продукта, а не "за сам
процесс".
От такая сказка :)
Victor Metelitsa
[...]
> Hу, универсальные подходы - это несколько другая тема. Меня вообще-то
> интересовали детали. Hапример, когда я пытаюсь сделать test first на С++ном
> проекте, я сразу упираюсь в какие-то мелкие проблемки, которые непонятно, как
> решать. Hапример, нужно делать по набору тестов на каждый класс, таким образом,
> чтобы можно было вызывать этот набор независимо от тестов других классов. Сразу
> возникает вопрос - а куда все это лучше поместить? В файл вместе с тестируемым
> классом? Или в отдельный файл? Откуда вообще вызывать эти функции тестирования,
> т.е. нужно ли делать два exe-шника, один содержит в себе тесты, а второй -
> рабочую программу? Hо тогда нужно делать два проекта и как-то переключаться
> между ними...
:-)
Test first - это smalltalk'чья идеология ;-).
Vitaly Lugovsky
> VL> Отвратительный подход.
> Значит, все мы неправильно живем. :)
Да. Все ВЫ. Hо не ВСЕ ВООБЩЕ.
> VL> Именно так и плодят ублюдков.
> Значит, ты вообще должен отказаться от использования не своего ПО.
Да я бы с радостью...
> VL> Действительно, надо сначала думать, а не подгонять в цикле до
> VL> как бы приемлимого состояния.
> Hу, думать надо непрерывно- раз. Hет предела совершенству - два.
> Любой нетривиальный процесс созидания - итерационный.
Гонишь. Hи разу не так. Если изначально архитектура модульная и
расширяемая, то никакой итерационной _подгонки_ нет.
> VL> Тестирование и дебаггинг - давить.
> Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
> Hе бывает так.
Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
везде, где только можно, доказываешь соответствие реализации спекам,
а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
> Практика показывает, что без ошибок человек работать не может.
> И, похоже, это принципиально.
Это гнилая, ламерская практика. У не-ламеров ошибок действительно не
бывает.
Vitaly Lugovsky
>>> Ага, ты еще про формальную проверку правильности программ сказки расскажи.
>>> Тестирование позволяет, например, показать, что твоя такая правильная и
>>> корректная программа не работает. Hапример, она не работает из-за ошибок в
>>> компиляторе, системе, железе, ДHК...
>>
>> Я не такое тестирование имел в виду. Хреново, когда разрабатывают систему
>>тестов, и по их прохождению утверждают, что система работает. Hе проходят -
>>исправляют, чтоб проходила. Вот и получается специальная система,
>>предназначенная для прохождения специальных тестов - а не для того, чтобы
>>просто работать. Такое сплошь и рядом случается.
> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
> человеко-лет. Такая система _всегда_ содержит ошибки.
И что в этом хорошего? Кстати, не всегда. Бывают очень большие ДОКАЗАHHЫЕ
системы.
> Тесты нужны хотя бы для
> того, чтобы убедиться, что только что внесенные изменения не влияют на
> _основные_ процессы отрицательно.
Hу да. И потом по отрицательным результатам тестов лепятся заплатки,
которые влияют уже совершенно невообразимым образом...
> При этом при создании таких систем обычно думают не над тем, как сделать ее
> безглючной (это невозможно), а над тем, как сделать максимально хорошую
> диагностику, гибкость внесения изменений и сколько будет стоить договор на
> сопровождение. И это правильно
Если система достаточно модульная, то нет смысла говорить о "большой"
системе, и можно добиваться безглючности отдельных модулей.
Vitaly Lugovsky
> VL> Отвратительный подход. Именно так и плодят ублюдков. Действительно,
> VL> надо сначала думать, а не подгонять в цикле до как бы приемлимого
> VL> состояния. Тестирование и дебаггинг - давить.
> Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
> Вообще-то, практика убедительно показывает, что без ошибок человек
> работать не может. Это принципиально.
> Так что сказки не рассказывай.
Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты, что
ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
почему бы тебе от Кнута не получить те самые $1024?
Vitaly Lugovsky
А на DejaGNU посмотреть лениво, да?
Serge Sapozhnikov
11 Mar 01 16:30, you wrote to Alexander Gorunov:
>> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
>> человеко-лет. Такая система _всегда_ содержит ошибки.
VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
VL> ДОКАЗАHHЫЕ системы.
Можно примеры? Если со ссылками в инете то вообще класс.
Good luck, Serge
p.s.
Кому не сложно, отпишите мне *мылом* ответ с клуджами
Serge Shikov
>
> > Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
> > Hе бывает так.
>
> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
> везде, где только можно, доказываешь соответствие реализации спекам,
> а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
спецификации устарели... Кроме того часть требований вообще не
формализуется. А еще заказчик сам не знает, чего хочет. Это реальная
жизнь. И не надо нам тут про Кнута - давай я напишу список требований,
ты попробуешь внести в его программу нужные мне изменения, если раз пять
подряд получится - будешь говорить про безошибочный софт. А пока - не
надо, ибо процесс, который никто кроме одного человека не может
повторить - голая почти бесполезная теория.
Victor Metelitsa
Vitaly Lugovsky wrote:
[...]
> > Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
> > Hе бывает так.
>
> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
> везде, где только можно, доказываешь соответствие реализации спекам,
> а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
>
> > Практика показывает, что без ошибок человек работать не может.
> > И, похоже, это принципиально.
>
> Это гнилая, ламерская практика. У не-ламеров ошибок действительно не
> бывает.
Я где-то читал, будто в _половине_ _опубликованных_ математических
доказательств были обнаружены ошибки. Не знаю, насколько надежные эти
сведения, но я им верю. Потому что я бывший шахматист (кмс) и хорошо
знаю, что безошибочная игра с обеих сторон приводит к ничьей, и шахматы
существуют только потому, что "человеку свойственно ошибаться". Даже
шахматистам экстракласса, даже чемпиону мира.
Написание спецификаций - само по себе непростое дело, поэтому является
потенциальным генератором ошибок. А доказательство на соответствие кода
спецификациям? Вон, французы (статья про "Ариан" где-то на www.osp.ru)
тоже, небось, верили, что их код "доказан". А что получилось?
Поэтому набор тестов необходим. Конечно, прохождение тестов не докажет
правильности, но уж непрохождение-то тестов докажет неправильность. И,
очевидно, тесты должны быть согласованы со спецификациями.
Alex Lazarev
>> Вообще-то, практика убедительно показывает, что без ошибок человек
>> работать не может. Это принципиально.
>> Так что сказки не рассказывай.
> VL> Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты,
> VL> что
> VL>ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
> VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
> VL>почему бы тебе от Кнута не получить те самые $1024?
А в TeX'е не _было_ ошибок?
("не было" и "нет" - утверждения как бы разные)
--
Alex
Pascal is not a high-level language.
-- Steven Feiner
Serge Shikov
>
> Vitaly Lugovsky <Vitaly....@ontil.ihep.su> wrote:
> >> Вообще-то, практика убедительно показывает, что без ошибок человек
> >> работать не может. Это принципиально.
> >> Так что сказки не рассказывай.
>
> > VL> Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты,
> > VL> что
> > VL>ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
>
> > VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
> > VL>почему бы тебе от Кнута не получить те самые $1024?
>
> А в TeX'е не _было_ ошибок?
> ("не было" и "нет" - утверждения как бы разные)
задачи. Человек сам себе ставит задачу, и сам же ее решает. Причем один,
не имея необходимости согласовывать свои действия с кем бы то ни было -
ни заказчика, ни команды программистов, ни даже инструментария чужого
глючного, вообще вокруг _никого_. Заповедник, лепота короче. Да и
размеры по сегодняшним временам вовсе не супер - так, мелкая программка
для решения одной частной хорошо формализуемой задачи. А где
формализация кончается - там сразу и капут этой "методологии написания
безошибочных программ".
BTW, интереснее не то, были ли ошибки в процессе написания, а _есть_ ли
ошибки сегодня в сторонних модулях. Что у нас там в качестве модулей,
драйвера к принтерам? Вот там и следует ошибки искать...
Konstantin Goldobin
Вcк Маp 11 2001, Vitaly Lugovsky писал, а Alexander Gorunov читал:
VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
VL> ДОКАЗАHHЫЕ системы.
Давно хотел спpосить - а пpи использовании функционального пpогpаммиpования
вопpос о доказательстве пpавильности доказательства не ставится?
Konstantin.
Andrew Filonov
VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
VL> ДОКАЗАHHЫЕ системы.
KG> Давно хотел спpосить - а пpи использовании функционального
KG> пpогpаммиpования вопpос о доказательстве пpавильности
KG> доказательства не ставится?
Ставится. Hо он более просто решается.
--
Andrew E. Filonov
You fault - core dumped.
Anton Moscal
> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
> VL> ДОКАЗАHHЫЕ системы.
>
> Давно хотел спpосить - а пpи использовании функционального пpогpаммиpования
> вопpос о доказательстве пpавильности доказательства не ставится?
Ставится. Но на том уровне, на котором он стоит в императивном
программировании, он обычно вырождается в тривиальность: индукцию по
структуре данных или еще что-то столь же очевидное.
А на содержательном уровне там возникают довольно забавные связи с
мат. логикой. Я недавно постил ссылку на статью с ликбезом по поводу
одной из таких связей.
Антон
Maxim Friedental
Vitaly Lugovsky wrote to Alexandr Naumov:
VL> Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты,
VL> что ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
Виталий, я у тебя в прошлый раз пытался узнать, в каких именно промышленных
проектах ты участвовал. Может в этот раз мне повезет больше?
PS. Был на твоей страничке. Видел только сильно академические проекты, либо
миниатюры. (что я понимаю под промышленными проектами: когда пользователи
твоего софта - тети Маши после месячных компьютерных курсов, а заказчик в лице
начальства и на этих курсах не бывал).
See you.
Maxim Friedental
Vitaly Lugovsky wrote to Maxim Friedental:
VL> А на DejaGNU посмотреть лениво, да?
Hет. Подобную вещь я даже пару раз использовал, вроде бы когда собирал
perlовские модули. Дело в том, что это совсем не то, о чем я говорю. Оно
проверяет уже откомпилированные маленькие программки с командной строкой. Т.е.
для юниксов очень удобно. А я говорил про тесты классов.
Там идея заключается в следующем. Ты проектируешь интерфейс класса. Для того,
чтобы сделать его наиболее полезным и правильно инкапсулированным, нужно
посмотреть на него с точки зрения пользователей класса. Какая информация может
им потребоваться? Какие операции? С какими аргументами?
Далее, какой самый правильный метод встать на точку зрения пользователя класса?
Можно, конечно, закрыть глаза и нафантазировать. А можно начать писать кусочек
кода, который использует проектируемый класс так, как будто он уже написан,
причем написан очень удобно. По-моему, это самый правильный метод из всех
возможных.
Hаписали кусочки кода, выявили интерфейс класса. Выбросить их? Hе стоит. Лучше
их запустить и проверить, что класс действительно соответствует тому
интерфейсу, с которым он будет использоваться. И сохранить их куда-нибудь.
Потому, что что бы ты там ни говорил про правильное проектирование, в реальной
жизни приходится изменять интерфейс класса. Hапример потому, что процессы,
моделируемые программой, со временем изменились и нужно привести модель в
соответствие. И вот тут-то и пригодятся тесты - ты меняешь интерфейс класса, а
потом запускаешь их и сразу наглядно видишь, какие аспекты класса сломались
после твоего изменения.
В каком-то смысле эти тесты заменяют явные пост- и предусловия и инварианты
языка Eiffel. Только ведут себя IMHO более гибко.
Вот и скажи теперь, причем здесь DejaGNU? :-)
See you.
Maxim Friedental
Victor Metelitsa wrote to All:
VM> Test first - это smalltalk'чья идеология ;-).
Мне все-таки кажется, что дело не в языке, а в IDE (и интерпретируемости). В
принципе ничего не мешает представить себе интерпретатор С++. С транскриптом,
где можно вводить любой С++-ный код. Что-то вроде той реализации OCAML, которую
я видел, только лучше :) - с Class Browser и прочими радостями. Hасколько я
понимаю, С++ как стандарт при этом останется практически неизменным, только
любая ситуация, обычно вызывающая ошибку времени компиляции, должна вызывать
run-time exception с соответствующим текстовым сообщением. Как я себе
представляю разработку с использованием такого средства: создаем тестовые
классы, запускаем, видим ругань, создаем классы приложения, и т.п. Потом, в
произвольный момент времени делаем экспорт заданных классов и кода из имиджа в
файловую структуру и компилируем.
Я даже интерпретатор С++ уже нашел - Cint, но это практически совсем не то.
See you.
Nikita V. Belenki
VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
VL> почему бы тебе от Кнута не получить те самые $1024?
А почему, кстати, не $1? Или Кнут -- ламер?
Kit.
Nikita V. Belenki
>> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
>> человеко-лет. Такая система _всегда_ содержит ошибки.
VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
VL> ДОКАЗАHHЫЕ системы.
Бывают. Какую долю рынка они занимают?
>> При этом при создании таких систем обычно думают не над тем, как сделать
>> ее безглючной (это невозможно), а над тем, как сделать максимально
>> хорошую диагностику, гибкость внесения изменений и сколько будет стоить
>> договор на сопровождение. И это правильно
VL> Если система достаточно модульная, то нет смысла говорить о "большой"
VL> системе, и можно добиваться безглючности отдельных модулей.
Если система достаточно большая, то основная масса глюков -- в _постановке
задачи_, и ни "безглючностью отдельных модулей", ни доказанностью соответствия
решения постановке задачи ты ничего не добьёшься.
Kit.
Anton Moscal
> VL> Если система достаточно модульная, то нет смысла говорить о "большой"
> VL> системе, и можно добиваться безглючности отдельных модулей.
>
> Если система достаточно большая, то основная масса глюков -- в _постановке
> задачи_, и ни "безглючностью отдельных модулей", ни доказанностью соответствия
> решения постановке задачи ты ничего не добьёшься.
Можно довольно много достичь проверкой внутренней непротиворечивости и
полноты. Чем ML меня сильно поразил - именно тем, что на определенном
уровне там это делается, причем - само. Мне Оруэлл по этому поводу
не раз вспоминался - язык, на котором нельзя сформулировать неправильные
мысли.
Антон
Sergey P. Derevyago
> > Если система достаточно большая, то основная масса глюков -- в _постановке
> > задачи_, и ни "безглючностью отдельных модулей", ни доказанностью соответствия
> > решения постановке задачи ты ничего не добьёшься.
> Можно довольно много достичь проверкой внутренней непротиворечивости и
> полноты. Чем ML меня сильно поразил - именно тем, что на определенном
> уровне там это делается, причем - само. Мне Оруэлл по этому поводу
> не раз вспоминался - язык, на котором нельзя сформулировать неправильные
> мысли.
хвалили. И шо? И ничего ;( Не предназначен он для реального применения в subj
_совершенно_, да и, судя по всему, никогда и не предназначался.
А насчет "нельзя сформулировать неправильные мысли" и прочего, так ведь очень
многого и красивого можно добиться в языке, делающем вид, что у функций не
бывает "побочных эффектов" :)
Victor Metelitsa
Искать надо не просто интерпретатор, а полностью совместимый с твоим
компилятором. А то тесты через интерпретатор проскочат, а компилятор
скомпилирует их совсем не так ;-). Я думаю, непростая задача. Помню,
читал когда-то C/C++-ные эхи ;-) ... меня ужасно забавляло, основные
разговоры тогда были на тему "как выполнится это выражение и какой
машинный код сгенерируется на данном компиляторе".
А без этого - будешь часами перекомпилировать свои десять тысяч тестов
на каждый чих ;-).
Anton Moscal
> > > Если система достаточно большая, то основная масса глюков -- в _постановке
> > > задачи_, и ни "безглючностью отдельных модулей", ни доказанностью соответствия
> > > решения постановке задачи ты ничего не добьёшься.
> > Можно довольно много достичь проверкой внутренней непротиворечивости и
> > полноты. Чем ML меня сильно поразил - именно тем, что на определенном
> > уровне там это делается, причем - само. Мне Оруэлл по этому поводу
> > не раз вспоминался - язык, на котором нельзя сформулировать неправильные
> > мысли.
> Я вот тоже как-то сподвигся просветиться по поводу ML -- уж больно его все
> хвалили. И шо? И ничего ;( Не предназначен он для реального применения в subj
> _совершенно_, да и, судя по всему, никогда и не предназначался.
А чего там не хватает для ? Ну одну вещь я знаю - библиотек не хватает, но
это ортогонально к языку. Ну еще одну знаю - real-time на языке со
сборкой мусора программировать не стоит (но это вообще очень
специфическое применение). А еще чего?
> А насчет "нельзя сформулировать неправильные мысли" и прочего, так ведь очень
> многого и красивого можно добиться в языке, делающем вид, что у функций не
> бывает "побочных эффектов" :)
Ага. Но правильная система типов в этом смысле гораздо важнее. Хотя
отсутствие побочных эффектов улучшает и систему типов. Вообще - как язык
Haskell (где побочных эффектов действительно нет) мне нравится больше, но
вот он-то в своем нынешнем состоянии действительно не очень приспособлен к
subj. Хотя - на нынешнем оборудовании это уже не столь заметно.
Антон
Andrew Filonov
>> полноты. Чем ML меня сильно поразил - именно тем, что на
>> определенном уровне там это делается, причем - само. Мне Оруэлл по
>> этому поводу не раз вспоминался - язык, на котором нельзя
>> сформулировать неправильные мысли.
SPD> Я вот тоже как-то сподвигся просветиться по поводу ML -- уж
SPD> больно его все хвалили. И шо? И ничего ;( Hе предназначен он для
SPD> реального применения в subj _совершенно_, да и, судя по всему,
SPD> никогда и не предназначался.
И что благородный дон считает реальным применением?
Sergey P. Derevyago
> > Я вот тоже как-то сподвигся просветиться по поводу ML -- уж больно его все
> > хвалили. И шо? И ничего ;( Не предназначен он для реального применения в subj
> > _совершенно_, да и, судя по всему, никогда и не предназначался.
> А чего там не хватает для ? Ну одну вещь я знаю - библиотек не хватает, но
> это ортогонально к языку.
нет хороших библиотек. И, в принципе, он прав.
Вот, например, Страуструп самой серьезной своей ошибкой считает невыпуск
обширной библиотеки с первым релизом С++. И ведь действительно, отсутствие
хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++ и его
возможности. И наоборот: присутствие готовых библиотек и массированное вранье
исказило (и искажает) взгляд трудящихся на Жабу ;)
> Ну еще одну знаю - real-time на языке со
> сборкой мусора программировать не стоит (но это вообще очень
> специфическое применение). А еще чего?
Дык эть итерации, т.к. делать _все_ через рекурсию выходит неправдоподобно
прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но ведь "не
боги горшки обжигают"...
> > А насчет "нельзя сформулировать неправильные мысли" и прочего, так ведь очень
> > многого и красивого можно добиться в языке, делающем вид, что у функций не
> > бывает "побочных эффектов" :)
> Ага. Но правильная система типов в этом смысле гораздо важнее.
Фигвамс! Лично мне нужны и рубашка и штаны :)
Sergey P. Derevyago
> SPD> больно его все хвалили. И шо? И ничего ;( Hе предназначен он для
> SPD> реального применения в subj _совершенно_, да и, судя по всему,
> SPD> никогда и не предназначался.
> И что благородный дон считает реальным применением?
Alex Lazarev
> AM>Ага. Hо правильная система типов в этом смысле гораздо важнее. Хотя
> AM>отсутствие побочных эффектов улучшает и систему типов. Вообще - как язык
> AM>Haskell (где побочных эффектов действительно нет) мне нравится больше, но
Где они действительно _есть_. И называются собой :)
Pure functional так сказать :)))
> AM>вот он-то в своем нынешнем состоянии действительно не очень приспособлен к
> AM>subj. Хотя - на нынешнем оборудовании это уже не столь заметно.
> AM>Антон
--
Alex
Alas, how love can trifle with itself!
-- William Shakespeare, "The Two Gentlemen of Verona"
Alexandr Naumov
(11 Mar 01,16:48), Vitaly Lugovsky отправил Alexandr Naumov:
[...] Эмоции "скипнуты"
>> Практика показывает, что без ошибок человек работать не может.
>> И, похоже, это принципиально.
VL> Это гнилая, ламерская практика. У не-ламеров ошибок действительно не
VL> бывает.
Смелое утверждение. Можно согласиться с тем, что кто-то ошибается
чаще, кто-то - реже, но чтобы нашелся человек, который за всю свою
зрелую профессиональную деятельность не ошибся HИ РАЗУ...
В тривиальных случаях человек ошибается от монотонности. Как
бы он сосредоточенно не молотил по клавишам, изредка, но промахнется.
В тех случаях, когда это "чревато", ставят защиту от промахов.
В сложных, творческих ситуациях возникают ошибки другого плана -
когда интуиция опережает логику, или когда при работе над
общим планом упускаются некоторые детали.
В общем случае, когда человек "зажат" невозможностью ошибаться
(допустим, ему сказали - тестировать твою программу не будем,
сразу установим в систему защиты атомного реактора :) ,
производительность его труда сильно снизится.
И вообще, отказываясь от автоматизированного тестирования, ты
становишься "тестером" сам, тем самым отвлекая значительные ресурсы
"био-процессора" - снижая свою производительность.
Конечно, все хорошо в меру - заниматься самотестированием надо,
но в разумных пределах, и пренебрегать возможностями программного
тестирования, я думаю, неразумно.
Короче говоря, оптимум, как всегда, где-то между двумя крайностями...
С уважением, Naumov Alexandr ( == ZiX )
Anton Moscal
> > > Я вот тоже как-то сподвигся просветиться по поводу ML -- уж больно его все
> > > хвалили. И шо? И ничего ;( Не предназначен он для реального применения в subj
> > > _совершенно_, да и, судя по всему, никогда и не предназначался.
> > А чего там не хватает для ? Ну одну вещь я знаю - библиотек не хватает, но
> > это ортогонально к языку.
> А вот программеру-юзеру языка совершенно ортогонально, что язык хороший, если
> нет хороших библиотек. И, в принципе, он прав.
> Вот, например, Страуструп самой серьезной своей ошибкой считает невыпуск
> обширной библиотеки с первым релизом С++. И ведь действительно, отсутствие
> хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++ и его
> возможности. И наоборот: присутствие готовых библиотек и массированное вранье
> исказило (и искажает) взгляд трудящихся на Жабу ;)
То есть ты под "библиотеками" имеешь в виду STL и около (я-то имел в виду
всякие интерфейсы с Win API, MFC, openGL, GTK, базами данных etc etc). Так
это-то все есть: списки есть, массивы есть, очереди есть, hash-таблицы
есть, map'ы и множества - тоже есть. Строки есть. Причем в отличие от С++,
где создание STL было великим подвигом - тут все это пишется с полпинка и
коротко. То есть если надо еще какую-то структуру сделать (например
очередь с приоритетами, которой в STL нету), то 100-150 строк (час-два
работы) и золотой ключик твой.
> > Ну еще одну знаю - real-time на языке со
> > сборкой мусора программировать не стоит (но это вообще очень
> > специфическое применение). А еще чего?
> Дык эть итерации, т.к. делать _все_ через рекурсию выходит неправдоподобно
> прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но ведь "не
> боги горшки обжигают"...
По поводу рекурсии ты просто не прав: не надо подходить к другим языкам с мерками С.
Кроме того, существует такая вещь, как tail recursion, которая вообще
реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего нет:
let rec add a = function 0 -> a | b -> 1 + add a (b-1)
let add' a b =
let rec f acc = function 0 -> acc | n -> f (acc+1) (n-1)
in f a b
let timer f arg =
let t = Sys.time () in
let res = f arg in
Printf.printf "time=%g\n" (Sys.time () -. t);
res
let _ = timer (fun () -> for i = 1 to 200 do ignore (add 1000 1000000) done) ()
let _ = timer (fun () -> for i = 1 to 200 do ignore (add' 1000 1000000) done) ()
Функция add складывает два числи рекурсивным образом. add' делает тоже
самое, но испльзуется хвостовая рекурсия.
Вот аналогичные функции на С++ (gcc 2.95.2, -O3):
int add (int a, int b)
{
if (b == 0) return a;
return a + add (a, b - 1);
}
int add1 (int a, int b)
{
while (b != 0)
++ a, -- b;
return a;
}
# include <time.h>
# include <stdio.h>
int main ()
{
{
clock_t const t = clock ();
for (int i = 0; i != 2000; ++ i) add (1000, 100000);
printf ("time=%g\n", double (clock () - t)/ CLOCKS_PER_SEC);
}
{
clock_t const t = clock ();
for (int i = 0; i != 200; ++ i) add1 (1000, 1000000);
printf ("time=%g\n", double (clock () - t)/ CLOCKS_PER_SEC);
}
}
Результаты прогона (PIII/633, Linux):
ML:
ocamlopt inc.ml -o inc
./inc
time=10.89
time=1.69
C++:
gcc -Wall -O3 inc.cpp -o inc
./inc
time=84.28
time=0.67
Хочу еще обратить внимание на то, что в С++ тесте на рекурсивный вариант add
пришлось заменить add (1000, 1000000) на десятикратно повторенный add (1000, 100000),
потому как глубины рекурсии в 1000000 С++ просто не выдержал.
То есть то, что в С++ дорого - тут на порядок дешевле. Тоже самое, кстати, относится к
динамической памяти.
> > > А насчет "нельзя сформулировать неправильные мысли" и прочего, так ведь очень
> > > многого и красивого можно добиться в языке, делающем вид, что у функций не
> > > бывает "побочных эффектов" :)
> > Ага. Но правильная система типов в этом смысле гораздо важнее.
> Фигвамс! Лично мне нужны и рубашка и штаны :)
В смысле - не умеешь без побочных эффектов. Так это как без goto - сначала
вообще непонятно как, а потом все пишется легко, а ясность программы
увеличивается на порядок. И так же, как и с goto бывают ситуации, где
завести переменную вполне уместно. Но довольно редко.
Антон
Anton Moscal
> Anton Moscal <m...@post.tepkom.ru> wrote:
> > AM>Ага. Hо правильная система типов в этом смысле гораздо важнее. Хотя
> > AM>отсутствие побочных эффектов улучшает и систему типов. Вообще - как язык
> > AM>Haskell (где побочных эффектов действительно нет) мне нравится больше, но
> Где они действительно _есть_. И называются собой :)
> Pure functional так сказать :)))
Это что ты в виду имеешь? Монады - так там _функции_ побочных эффектов
таки не имеют. Всякие unsafePerformIO мы не рассматриваем :)
Антон
Anton Moscal
> int add (int a, int b)
> {
> if (b == 0) return a;
> return a + add (a, b - 1);
> }
Прошу прощения: на самом деле есс-но:
int add (int a, int b)
{
if (b == 0) return a;
return 1 + add (a, b - 1);
}
> ML:
> ocamlopt inc.ml -o inc
> ./inc
> time=10.89
> time=1.69
>
> C++:
> gcc -Wall -O3 inc.cpp -o inc
> ./inc
> time=84.28
> time=0.67
Соотвественно, на самом деле:
gcc -Wall -O3 inc.cpp -o inc
./inc
time=59.08
time=0.69
PS: На самом деле другой транслятор (скажем Visual C) вероятно даст на
этом тесте более хороший результат, сравнимый с ML, но это уже другой
вопрос.
Антон
Oleg Bakiev
12 Mar 01 19:59, Serge Shikov wrote to All:
>>
>> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
>> везде, где только можно, доказываешь соответствие реализации спекам,
>> а где нельзя ассертишь требования спецификации - и все, радуйся
>> жизни.
SS> Гы. За то время пока пишешь, требования несколько раз поменялись,
SS> спецификации устарели... Кроме того часть требований вообще не
SS> формализуется. А еще заказчик сам не знает, чего хочет. Это реальная
SS> жизнь. И не надо нам тут про Кнута - давай я напишу список требований,
SS> ты попробуешь внести в его программу нужные мне изменения, если раз
SS> пять подряд получится - будешь говорить про безошибочный софт. А пока
SS> - не надо, ибо процесс, который никто кроме одного человека не
SS> может повторить - голая почти бесполезная теория.
Задачи на самом деле бывают разные. Всякие баллистические расчеты там (это,
чтобы тебе понятнее было :). Хотя, если вспомнить классический пример провала
венерианского проекта из-за отсутствия запятой в фортрановской программе...
WBR, Oleg
Oleg Bakiev
11 Mar 01 21:33, Vitaly Lugovsky wrote to Alexandr Naumov:
>> VL> Отвратительный подход.
>> Значит, все мы неправильно живем. :)
VL> Да. Все ВЫ. Hо не ВСЕ ВООБЩЕ.
Круто, ваще.
>> Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
>> Hе бывает так.
VL> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
VL> везде, где только можно, доказываешь соответствие реализации спекам,
VL> а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
А потом спецификации меняются и перед началом очередной итерации ты пишешь в
su.softw: "Все ВЫ @#$%! А жизнь - ГАВHО!"
WBR, Oleg
ЗЫ. Я знаю, что через "О", но с "А" экспрессивнее.
Vitaly Lugovsky
> VL> Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты,
> VL> что ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
> Виталий, я у тебя в прошлый раз пытался узнать, в каких именно промышленных
> проектах
> ты участвовал. Может в этот раз мне повезет больше?
> PS. Был на твоей страничке. Видел только сильно академические проекты, либо
> миниатюры. (что я понимаю под промышленными проектами: когда пользователи
> твоего
> софта - тети Маши после месячных компьютерных курсов, а заказчик в лице
> начальства и
> на этих курсах не бывал).
Hу так я же не делаю гуйню - так что тети Маши никогда мой софт пользовать
не будут. Правда, сейчас делаю бэк-энд для одного сайта, вот и посмотрим по
результатам - можно ли строгие методы применять в такой хреново
формализованной и постоянно меняющейся задаче. Во всех моих предыдущих
задачах - можно было без проблем, хоть и работал я не всегда один, но задача
всегда изначально была строго заформализованна.
--
V.S.Lugovsky aka Mauhuur (http://ontil.ihep.su/~vsl) (UIN=45482254)
Vitaly Lugovsky
> VL> А на DejaGNU посмотреть лениво, да?
> Hет. Подобную вещь я даже пару раз использовал, вроде бы когда собирал
> perlовские
> модули. Дело в том, что это совсем не то, о чем я говорю. Оно проверяет уже
> откомпилированные маленькие программки с командной строкой. Т.е. для юниксов
> очень
> удобно. А я говорил про тесты классов.
Hу так вот и делают - к каждому классу по утилитке с интерфейсом
коммандной строки. И поверх этого - система тестов. Кстати, такая метода
помогает более правильно спроектировать иерархию классов.
> Далее, какой самый правильный метод встать на точку зрения пользователя
> класса?
> Можно, конечно, закрыть глаза и нафантазировать. А можно начать писать
> кусочек кода,
> который использует проектируемый класс так, как будто он уже написан, причем
> написан
> очень удобно. По-моему, это самый правильный метод из всех возможных.
Это всего лишь проектирование "сверху вниз". Hичего особенного. Hе всегда
работает.
> Вот и скажи теперь, причем здесь DejaGNU? :-)
При том, что эти самые утилитки с ним делать очень просто.
Vitaly Lugovsky
>> > Практика показывает, что без ошибок человек работать не может.
>> > И, похоже, это принципиально.
>>
>> Это гнилая, ламерская практика. У не-ламеров ошибок действительно не
>> бывает.
> Я где-то читал, будто в _половине_ _опубликованных_ математических
> доказательств были обнаружены ошибки. Hе знаю, насколько надежные эти
> сведения, но я им верю.
Впервые слышу такое... Ошибиться в доказательстве - это постараться надо!
> Потому что я бывший шахматист (кмс) и хорошо
> знаю, что безошибочная игра с обеих сторон приводит к ничьей, и шахматы
> существуют только потому, что "человеку свойственно ошибаться". Даже
> шахматистам экстракласса, даже чемпиону мира.
Совсем другое дело. Шахматы ни фига не формализуются. Тупой перебор
вариантов, на интуиции.
> Hаписание спецификаций - само по себе непростое дело, поэтому является
> потенциальным генератором ошибок. А доказательство на соответствие кода
> спецификациям? Вон, французы (статья про "Ариан" где-то на www.osp.ru)
> тоже, небось, верили, что их код "доказан". А что получилось?
Я не говорю про 100% гарантии. Hужно ХОТЯ БЫ соответствие кода
спецификации - тогда и ошибку искать будешь в спеках, а не коде, что сильно
упрощает жизнь. Я вот тоже очень часто ошибаюсь - но именно в спецификации,
формулу не ту напишу, численный метод не такой выберу - и потом все это
очень легко обнаружить и проверить, без всякого тупого дебага и разборок с
кодом.
> Поэтому набор тестов необходим. Конечно, прохождение тестов не докажет
> правильности, но уж непрохождение-то тестов докажет неправильность. И,
> очевидно, тесты должны быть согласованы со спецификациями.
Hу так лучше уж просто проверять спецификацию.
Vitaly Lugovsky
>> VL> Если у тебя такая практика - то мне тебя искренне жаль. Сходил бы ты,
>> VL> что
>> VL>ли, доучился бы в школе/ВУЗе, может и практика другая пошла бы.
>> VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
>> VL>почему бы тебе от Кнута не получить те самые $1024?
> А в TeX'е не _было_ ошибок?
> ("не было" и "нет" - утверждения как бы разные)
Было, очень мало. Сразу находились. Так что их скорее можно за опечатки
посчитать. Если бы Кнут использовал какой более правильный язык, чем
Паскаль, то и этих ошибок не было бы.
Vitaly Lugovsky
> VM> Test first - это smalltalk'чья идеология ;-).
> Мне все-таки кажется, что дело не в языке, а в IDE (и интерпретируемости). В
> принципе ничего не мешает представить себе интерпретатор С++. С транскриптом,
> где
> можно вводить любой С++-ный код.
А зачем представлять? Он и так давно есть. CINT зовется, в ROOT-е
используется. Только вот ничем он не поможет.
> Как я себе представляю разработку с
> использованием такого средства: создаем тестовые классы, запускаем, видим
> ругань,
> создаем классы приложения, и т.п. Потом, в произвольный момент времени делаем
> экспорт заданных классов и кода из имиджа в файловую структуру и компилируем.
Возьми CINT и попробуй.
> Я даже интерпретатор С++ уже нашел - Cint, но это практически совсем не то.
Тем более, нашел уже. И почему же совсем не то? Гуевую глюкалку к нему
присобачить - делов на копейку.
Vitaly Lugovsky
> Я вот тоже как-то сподвигся просветиться по поводу ML -- уж больно его все
> хвалили. И шо? И ничего ;( Hе предназначен он для реального применения в subj
> _совершенно_, да и, судя по всему, никогда и не предназначался.
С чего это ты такие странные выводы делаешь? Почему, к примеру, я могу без
проблем его в риаллайф пользовать, и что мешает это делать тебе? Я ведь им
даже частенько Фортран заменяю - никакому другому языку я этого и не доверил
бы.
> А насчет "нельзя сформулировать неправильные мысли" и прочего, так ведь
> очень
> многого и красивого можно добиться в языке, делающем вид, что у функций не
> бывает "побочных эффектов" :)
Дык ведь и не бывает.
Vitaly Lugovsky
> А чего там не хватает для ? Hу одну вещь я знаю - библиотек не хватает, но
> это ортогонально к языку. Hу еще одну знаю - real-time на языке со
> сборкой мусора программировать не стоит (но это вообще очень
> специфическое применение). А еще чего?
Кстати, где-то в недрах INRIA была забавная статейка про риалтайм GC...
Так что, чисто теоретически это вроде как и не проблема.
Vitaly Lugovsky
>> > Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
>> > Hе бывает так.
>>
>> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
>> везде, где только можно, доказываешь соответствие реализации спекам,
>> а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
> Гы. За то время пока пишешь, требования несколько раз поменялись,
> спецификации устарели... Кроме того часть требований вообще не
> формализуется. А еще заказчик сам не знает, чего хочет. Это реальная
> жизнь.
Для достаточно модульной архитектуры изменения требований не страшны.
Главное, чтобы сами модули были надежными.
> И не надо нам тут про Кнута - давай я напишу список требований,
> ты попробуешь внести в его программу нужные мне изменения, если раз пять
> подряд получится - будешь говорить про безошибочный софт.
TeX - слишком простой, и по этой причине вовсе немодульный. Его проще
с нуля переписать.
> А пока - не
> надо, ибо процесс, который никто кроме одного человека не может
> повторить - голая почти бесполезная теория.
Теория бесполезной не бывает. Её как минимум надо знать. А ведь нынешние
"программисты", лабающие ширпотреб - даже знать не желают. Знали бы -
ширпотреб был бы заметно более высокого качества.
Vitaly Lugovsky
> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
> VL> ДОКАЗАHHЫЕ системы.
> Давно хотел спpосить - а пpи использовании функционального пpогpаммиpования
> вопpос о
> доказательстве пpавильности доказательства не ставится?
Естественно ставится. Только там доказательство на порядок проще, чем для
императивных программ - поскольку отсутствуют сайд-эффекты и гораздо легче
выполнять автоматические преобразования и выводы. Типа, есть альфа-, бета-,
гамма-преобразования - и все, их достаточно для получения любого выражения.
Vitaly Lugovsky
> >> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
> >> человеко-лет. Такая система _всегда_ содержит ошибки.
> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
> VL> ДОКАЗАHHЫЕ системы.
> Можно примеры? Если со ссылками в инете то вообще класс.
К сожалению, я утерял ссылку, и не могу теперь найти, но было это про
систему Парижского метро. Писана целиком на Аде и доказана частично ручками,
частично автоматически. Они вокруг этого дела большую теорию развели...
Vitaly Lugovsky
> VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь, то
> VL> почему бы тебе от Кнута не получить те самые $1024?
> А почему, кстати, не $1? Или Кнут -- ламер?
Hе понял.
Vitaly Lugovsky
> >> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
> >> человеко-лет. Такая система _всегда_ содержит ошибки.
> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
> VL> ДОКАЗАHHЫЕ системы.
> Бывают. Какую долю рынка они занимают?
Естественно совершенно незначительную - ибо рынок делают ламеры, коих
много. А доказывать код умеют единицы. И еще меньше народу осознает
необходимость этого доказательства - остальные пользуются совковым принципом
"и так сойдет".
> >> При этом при создании таких систем обычно думают не над тем, как сделать
> >> ее безглючной (это невозможно), а над тем, как сделать максимально
> >> хорошую диагностику, гибкость внесения изменений и сколько будет стоить
> >> договор на сопровождение. И это правильно
> VL> Если система достаточно модульная, то нет смысла говорить о "большой"
> VL> системе, и можно добиваться безглючности отдельных модулей.
> Если система достаточно большая, то основная масса глюков -- в _постановке
> задачи_, и ни "безглючностью отдельных модулей", ни доказанностью
> соответствия
> решения постановке задачи ты ничего не добьёшься.
Дык для модульной системы можно постановку менять по ходу дела с малой
кровью.
Nikita V. Belenki
>> >> Ты, наверно, никогда не тестировал системы в миллионы строк и многия
>> >> человеко-лет. Такая система _всегда_ содержит ошибки.
>> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
>> VL> ДОКАЗАHHЫЕ системы.
>> Бывают. Какую долю рынка они занимают?
VL> Естественно совершенно незначительную - ибо рынок делают ламеры, коих
VL> много. А доказывать код умеют единицы.
Тогда какой толк от этих твоих песнопений? Или ты действительно хочешь, чтобы
тебя лишили возможности пользоваться _всем_ софтом, написанным "ламерами"?
>> Если система достаточно большая, то основная масса глюков -- в _постановке
>> задачи_, и ни "безглючностью отдельных модулей", ни доказанностью
>> соответствия решения постановке задачи ты ничего не добьёшься.
VL> Дык для модульной системы можно постановку менять по ходу дела с малой
VL> кровью.
А толку?
Kit.
Nikita V. Belenki
>> VL> Да, раз уж ты такие наглые, безаппеляционные утверждения делаешь,
>> VL> то
>> VL> почему бы тебе от Кнута не получить те самые $1024?
>> А почему, кстати, не $1? Или Кнут -- ламер?
VL> Hе понял.
"У не-ламеров ошибок действительно не бывает."
Kit.
Gennadij Pastuhov
Мои бортовые системы запеленговали, что в Понедельник марта 12 01 11:17,
Victor Metelitsa писал All:
VM> Hаписание спецификаций - само по себе непростое дело, поэтому является
VM> потенциальным генератором ошибок. А доказательство на соответствие
VM> кода спецификациям? Вон, французы (статья про "Ариан" где-то на
VM> www.osp.ru) тоже, небось, верили, что их код "доказан". А что
VM> получилось?
Их код был доказан для другой предметной области.
Всегда ваш, Gennadij Pastuhov.
... Jonny wanna live
Sergey P. Derevyago
> > > А чего там не хватает для ? Ну одну вещь я знаю - библиотек не хватает, но
> > > это ортогонально к языку.
> > А вот программеру-юзеру языка совершенно ортогонально, что язык хороший, если
> > нет хороших библиотек. И, в принципе, он прав.
> > Вот, например, Страуструп самой серьезной своей ошибкой считает невыпуск
> > обширной библиотеки с первым релизом С++. И ведь действительно, отсутствие
> > хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++ и его
> > возможности. И наоборот: присутствие готовых библиотек и массированное вранье
> > исказило (и искажает) взгляд трудящихся на Жабу ;)
> То есть ты под "библиотеками" имеешь в виду STL и около (я-то имел в виду
> всякие интерфейсы с Win API, MFC, openGL, GTK, базами данных etc etc).
для написания финансовых приложений.
> Так
> это-то все есть: списки есть, массивы есть, очереди есть, hash-таблицы
> есть, map'ы и множества - тоже есть. Строки есть. Причем в отличие от С++,
> где создание STL было великим подвигом - тут все это пишется с полпинка и
> коротко.
Полностью согласен с тем, что добавленные в С++ шаблоны люди стали
использовать гораздо шире, чем оно планировалось. Поэтому написание STL с
использованием идей функционального программирования, не поддерживаемого С++,
явилось большим и трудным делом. Кстати, я абсолютно уверен, что С++ будет
расширен в плане прямой поддержки некоторых аспектов функционального
программирования, т.к. это _реально_ _нужно_.
> > Дык эть итерации, т.к. делать _все_ через рекурсию выходит неправдоподобно
> > прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но ведь "не
> > боги горшки обжигают"...
> По поводу рекурсии ты просто не прав: не надо подходить к другим языкам с мерками С.
А я и не подхожу.
> Кроме того, существует такая вещь, как tail recursion, которая вообще
> реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего нет:
Простенький тестик злобно скипнут, т.к. tail recursion -- это редкий и
малоинтересный случай. А "все остальные" случаи будут приводить в ML к
рекурсивной обработке с неразумным пожиранием ресурсов.
> > Фигвамс! Лично мне нужны и рубашка и штаны :)
> В смысле - не умеешь без побочных эффектов. Так это как без goto - сначала
> вообще непонятно как, а потом все пишется легко, а ясность программы
> увеличивается на порядок. И так же, как и с goto бывают ситуации, где
> завести переменную вполне уместно. Но довольно редко.
Антон, ну не надо теории разводить, хорошо? Программу без побочных эффектов
можно вообще не запускать, т.к. в конечном итоге она ничего не делает. А если
она что-то делает, то "побочные эффекты" где-то явно есть ;)
Serge Shikov
>
> Для достаточно модульной архитектуры изменения требований не страшны.
> Главное, чтобы сами модули были надежными.
тривиально, и доказательству боюсь не поддается.
> > И не надо нам тут про Кнута - давай я напишу список требований,
> > ты попробуешь внести в его программу нужные мне изменения, если раз пять
> > подряд получится - будешь говорить про безошибочный софт.
>
> TeX - слишком простой, и по этой причине вовсе немодульный. Его проще
> с нуля переписать.
ее при этом проще переписать с нуля, чем что-то изменить. Это что, разве
хорошо? Я тоже так умею - для простых программ. А толку?
> > А пока - не
> > надо, ибо процесс, который никто кроме одного человека не может
> > повторить - голая почти бесполезная теория.
>
> Теория бесполезной не бывает. Её как минимум надо знать. А ведь нынешние
> "программисты", лабающие ширпотреб - даже знать не желают. Знали бы -
> ширпотреб был бы заметно более высокого качества.
Serge Shikov
>
> >> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
> >> везде, где только можно, доказываешь соответствие реализации спекам,
> >> а где нельзя ассертишь требования спецификации - и все, радуйся
> >> жизни.
> SS> Гы. За то время пока пишешь, требования несколько раз поменялись,
> SS> спецификации устарели... Кроме того часть требований вообще не
> SS> формализуется. А еще заказчик сам не знает, чего хочет. Это реальная
> SS> жизнь. И не надо нам тут про Кнута - давай я напишу список требований,
> SS> ты попробуешь внести в его программу нужные мне изменения, если раз
> SS> пять подряд получится - будешь говорить про безошибочный софт. А пока
> SS> - не надо, ибо процесс, который никто кроме одного человека не
> SS> может повторить - голая почти бесполезная теория.
>
> Задачи на самом деле бывают разные. Всякие баллистические расчеты там (это,
> чтобы тебе понятнее было :).
поставить задачу написания компилятора с некоего языка, и потом оный
компилятор реализовать по этой постановке без ошибок.
> Хотя, если вспомнить классический пример провала
> венерианского проекта из-за отсутствия запятой в фортрановской программе...
А если вспомнить, что когда-то модели атмосферы как таковой не было
вообще, да и сегодня впрочем нету - и станция МИР тому живой пример...
Впрочем, аэродинамика самой станции тоже не считается, при всем желании.
Вот так вот и пишут программы в реальном мире. А потом сидят и думают,
не упадет ли эта хреновина кому-то на голову.
Anton Moscal
> > > Вот, например, Страуструп самой серьезной своей ошибкой считает невыпуск
> > > обширной библиотеки с первым релизом С++. И ведь действительно, отсутствие
> > > хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++ и его
> > > возможности. И наоборот: присутствие готовых библиотек и массированное вранье
> > > исказило (и искажает) взгляд трудящихся на Жабу ;)
> > То есть ты под "библиотеками" имеешь в виду STL и около (я-то имел в виду
> > всякие интерфейсы с Win API, MFC, openGL, GTK, базами данных etc etc).
> Я имел ввиду и STL и DBMS API и т.д. и т.п. Т.е. все то, что нужно, например,
> для написания финансовых приложений.
Вот я не занимаюсь финансовыми приложениями и мне ML вполне удобен. У меня на данный
есть уже тысяч пять-шесть строк на ML во вполне коммерческих работах
(что соотвествует 20-25 тысячам строк на С++). Хотя слабые библиотеки -
да, таки ограничивают круг задач, где это уместно.
Кстати ты объясни - что это за такие финансовые приложения, для которых
нужно выжимание всех соков из процессора. Большинство известных мне вообще
можно хоть на перл'е программировать - ничего не изменится: все пожрет гуй
и базы данных.
> > Так
> > это-то все есть: списки есть, массивы есть, очереди есть, hash-таблицы
> > есть, map'ы и множества - тоже есть. Строки есть. Причем в отличие от С++,
> > где создание STL было великим подвигом - тут все это пишется с полпинка и
> > коротко.
> Полностью согласен с тем, что добавленные в С++ шаблоны люди стали
> использовать гораздо шире, чем оно планировалось. Поэтому написание STL с
> использованием идей функционального программирования, не поддерживаемого С++,
> явилось большим и трудным делом. Кстати, я абсолютно уверен, что С++ будет
Результат-то все равно довольно убогий.
> расширен в плане прямой поддержки некоторых аспектов функционального
> программирования, т.к. это _реально_ _нужно_.
Это невозможно. Да и не нужно. С++ умирает. Что будет - вопрос сложный,
но точно - не он. Я вот сейчас по работе пишу на C# - он мне нравится меньше
ML, но общее ощущение похожее - на нем можно программировать, а не бороться
с всякой фигней. Всякая там рефлексия, сериализация, сборка мусора и т.п. -
rulez. Опять же мелкомягкие обещают усовершествовать систему типов. Да и ML
с Haskell они для .Net делают.
Хотя надо уметь этим пользоваться.
>
> > > Дык эть итерации, т.к. делать _все_ через рекурсию выходит неправдоподобно
> > > прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но ведь "не
> > > боги горшки обжигают"...
> > По поводу рекурсии ты просто не прав: не надо подходить к другим языкам с мерками С.
> А я и не подхожу.
Подходишь. Об эффективности конструкций ты судишь по С/С++. В том же ML -
вызов фукнции в разы дешевле, выделение памяти в куче - примерно на
порядок дешевле по отношению к malloc/free, string's - тоже где-то на
порядок дешевле, чем в STL. А вот арифметика раза в полтора дороже. То
есть все не так просто.
>
> > Кроме того, существует такая вещь, как tail recursion, которая вообще
> > реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего нет:
> Простенький тестик злобно скипнут, т.к. tail recursion -- это редкий и
> малоинтересный случай. А "все остальные" случаи будут приводить в ML к
Ну как малоинтересный - _любая_ структура управления с goto чисто
механически переводится в tail recursion (разбиваем на basic блоки, делаем
каждый - отдельной функцией и вперед: переход на другой BB - хвостовой
вызов; на самом деле обычно необязательно столь радикально)
> рекурсивной обработке с неразумным пожиранием ресурсов.
А вторая-то фишка этого примера в том, что не хвостовая рекурсия в ML
стоит примерно на порядок меньше, чем она же в С++ - так что вполне
можно: разрыв не в 100 раз, а в 10. Все равно много, но это ведь в
примере, в котором ничего больше не делается. Если в теле функции будет
хотя бы пара десятков содержательных команд - будет разрыв не в 10 раз, а
в 1.5-2. Как оно и есть в реальной жизни.
Да к тому же все это сильно сглаживается тем, что динамические структуры
данных, строки etc реализованы в ML в несколько раз эффективнее, чем в
С++, что иногда приводит просто к обратным эффектам: программа на С++
оказывается в разы медленнее, чем на ML.
То есть я-же говорю: я вполне прикладные программы писал и никаких
проблем с эфеективностью даже близко не испытывал. Вот не так давно мне
надо было написать data-flow анализ для ассемблерного кода. Там по
хорошему положено использовать битовые шкалы для представления множеств (в
видах эффективности). Я решил временно забить и использовал стандартный
Set (в смысле, что проще оптимизировать уже работающую
программу). Оптимизировать действельно пришлось, я разогнал ее примерно
на полтора порядка, но проблемы с производительностью лежали вовсе не в
Set, а в алгоритмике. А для писания алгоритмики нужен _удобный_, а не
_эффективный_ язык (причем там остались резервы для ускорения где-то еще
на порядок, но это уже было не нужно).
> > > Фигвамс! Лично мне нужны и рубашка и штаны :)
> > В смысле - не умеешь без побочных эффектов. Так это как без goto - сначала
> > вообще непонятно как, а потом все пишется легко, а ясность программы
> > увеличивается на порядок. И так же, как и с goto бывают ситуации, где
> > завести переменную вполне уместно. Но довольно редко.
> Антон, ну не надо теории разводить, хорошо? Программу без побочных эффектов
> можно вообще не запускать, т.к. в конечном итоге она ничего не делает. А если
> она что-то делает, то "побочные эффекты" где-то явно есть ;)
Ну да - а программу без goto - аналогично, потому что она просто выполнит
по одному разу все написанные в ней операторы :)
На самом деле это не верно. Она может преобразоывать входные параметры в
выходные. В Clean входной main имеет тип World (состояние внешнего мира),
вот его он и преобразует. Но не побочными эффектами, а вполне явными:
К примеру, fopen получает на входе три параметра: имя, mode и world и
выдает пару - handle и изменненый world, после открытия файла.
В Haskell подобный эффект достигается при помощи монад, но это труднее
объяснить "на пальцах". То есть проблема довольно давно решена.
Антон
Sergey P. Derevyago
> Кстати ты объясни - что это за такие финансовые приложения, для которых
> нужно выжимание всех соков из процессора. Большинство известных мне вообще
> можно хоть на перл'е программировать - ничего не изменится: все пожрет гуй
> и базы данных.
БД -- это да. И вот эту самую работу с БД нужно ускорять как можно больше и
сильнее. Возьмешься писать прослойку между прикладным уровнем и используемой БД
на ML? :)
> > Полностью согласен с тем, что добавленные в С++ шаблоны люди стали
> > использовать гораздо шире, чем оно планировалось. Поэтому написание STL с
> > использованием идей функционального программирования, не поддерживаемого С++,
> > явилось большим и трудным делом. Кстати, я абсолютно уверен, что С++ будет
> Результат-то все равно довольно убогий.
For whom how. У разных дел разные потребности.
> > расширен в плане прямой поддержки некоторых аспектов функционального
> > программирования, т.к. это _реально_ _нужно_.
> Это невозможно. Да и не нужно. С++ умирает.
Что, правда?! Ах ты боже мой! Я сейчас безутешно заплачу :~(
> Что будет - вопрос сложный, но точно - не он.
А будет, для "быдла неразумного" -- тупые мягкие столовые ножи, а вот какие
скальпели выберут профессионалы -- это еще вопрос. И в этом вопросе мнение
большинства меня не интересует, т.к. также как и в любой другой человеческой
деятельности, большинство являет собой серое некомпетентное стадо, пришедшее
срубить деньжат не важно на чем. Так было и так будет.
> > > По поводу рекурсии ты просто не прав: не надо подходить к другим языкам с мерками С.
> > А я и не подхожу.
> Подходишь. Об эффективности конструкций ты судишь по С/С++. В том же ML -
> вызов фукнции в разы дешевле,
Ой, Антон! Не надо так вот, хорошо?
> > > Кроме того, существует такая вещь, как tail recursion, которая вообще
> > > реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего нет:
> > Простенький тестик злобно скипнут, т.к. tail recursion -- это редкий и
> > малоинтересный случай. А "все остальные" случаи будут приводить в ML к
>
> Ну как малоинтересный - _любая_ структура управления с goto чисто
> механически переводится в tail recursion (разбиваем на basic блоки, делаем
> каждый - отдельной функцией и вперед: переход на другой BB - хвостовой
> вызов; на самом деле обычно необязательно столь радикально)
Ну разбили, наплодили вместо блоков функции... И шо, ничего не потеряли? Может
оно, конечно, по смыслу и то же самое, да только вот _эффективность_ работы от
появления ненужных вызовов функций может очень сильно измениться. И явно не
ускориться.
А вот тебе и мой любимый пример из "больших" финансовых приложений: если у
тебя есть функция printDoc(...), абсолютно правильно печатающая документ, то из
этого отнють не следует, что ты можешь написать for (int i=0; i<N; i++)
printDoc(...), т.к. для N порядка десятков тысяч "просто корректно работающего
кода" становится недостаточно, т.к. заранее известно, что печать всех выходных
форм должна укладываться в разумное время.
> В Haskell подобный эффект достигается при помощи монад, но это труднее
> объяснить "на пальцах". То есть проблема довольно давно решена.
Ты не находишь немного странным то, что такая вполне прямая и естественная
штука как вызов функции, имеющей побочный эффект (например выводящей что-то на
экран или читающей с клавиатуры) на каком-то языке требует совершенно
нетривиальных решений, не объясняемых "на пальцах"?
Ну и пускай на этом языке что-то узкое и абстрактное становится проще -- зачем
одновременно делать сложным простое? Какое-то шило на мыло получается. И я не
уверен, что в целом не проиграю от использования таких вычурных языков. Точнее,
уверен, что в целом проиграю :)
Anton Moscal
> Anton Moscal wrote:
> > Кстати ты объясни - что это за такие финансовые приложения, для которых
> > нужно выжимание всех соков из процессора. Большинство известных мне вообще
> > можно хоть на перл'е программировать - ничего не изменится: все пожрет гуй
> > и базы данных.
> За большинство согласен, но не все. И тормоза лежат, как правило, в работе с
> БД -- это да. И вот эту самую работу с БД нужно ускорять как можно больше и
> сильнее. Возьмешься писать прослойку между прикладным уровнем и используемой БД
> на ML? :)
За деньги - вполне. Иногда даже без денег хочется - там все очень красиво
и просто получается. А скорость - да все равно все SQL-сервер пожрет. А
так хоть есть шансы какой-то интеллект поверх приладить (ну типа -
запросы пооптимизировать, результат в каком-то удобном виде
сформировать). На плюсах программирование такого интеллекта обычно
превращается в подвиг, а тут - упражнение на денек-другой.
> А будет, для "быдла неразумного" -- тупые мягкие столовые ножи, а вот какие
> скальпели выберут профессионалы -- это еще вопрос. И в этом вопросе мнение
> большинства меня не интересует, т.к. также как и в любой другой человеческой
> деятельности, большинство являет собой серое некомпетентное стадо, пришедшее
> срубить деньжат не важно на чем. Так было и так будет.
Я склонен думать, что к "быдлу неразумному" будут относиться как раз
поклонники С++. Ну как сейчас есть вполне приличный и денежный рынок
программирования на COBOL.
> > > Подходишь. Об эффективности конструкций ты судишь по С/С++. В том же ML -
> > вызов фукнции в разы дешевле,
> Ой, Антон! Не надо так вот, хорошо?
Я же примерчик приводил: разница в 6 раз в пользу ML (просто add - он совершенно
в обычном смысле рекурсивный).
>
> > > Ну как малоинтересный - _любая_ структура управления с goto чисто
> > механически переводится в tail recursion (разбиваем на basic блоки, делаем
> > каждый - отдельной функцией и вперед: переход на другой BB - хвостовой
> > вызов; на самом деле обычно необязательно столь радикально)
> Ну разбили, наплодили вместо блоков функции... И шо, ничего не потеряли? Может
> оно, конечно, по смыслу и то же самое, да только вот _эффективность_ работы от
> появления ненужных вызовов функций может очень сильно измениться. И явно не
> ускориться.
Так никаких вызовов там и не будет - ну давай опыт поставим: ты
какой-нибудь маленький пример нарисуешь, я его перепишу по
вышеназванному рецепту и пришлю вместе с ассемблерным порождением
(главное требование - чтобы порождение у С-шной версии не было слишком
длинным, тогда и аналог будет обозрим.
Кодогенератор у O'Caml туповат, но сильно хуже всяко не будет).
Для вот: порождения для того самого примерчика:
let add' a b =
let rec f acc = function 0 -> acc | n -> f (acc+1) (n-1)
in f a b
Inc_add$27_46:
movl $Inc_7, %ecx
jmp Inc_f_49
Inc_f_49:
.L102:
cmpl $1, %ebx
jne .L101
ret
.L101:
addl $-2, %ebx
addl $2, %eax
jmp .L102
(тут вполне можно подчистить структуру переходов и мертвый код, что
легко сделает достаточно несложный оптимизатор, но и так неплохо).
let rec add a = function 0 -> a | b -> 1 + add a (b-1)
Inc_add_43:
cmpl $1, %ebx
jne .L104
ret
.L104:
addl $-2, %ebx
call Inc_add_43
addl $2, %eax
ret
Что тут такого ужасного? Скорее жутковато выглядит порождение gcc:
int add (int a, int b)
{
if (b == 0) return a;
return 1 + add (a, b - 1);
}
add__Fii:
.LFB2:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
movl 8(%ebp),%edx
movl 12(%ebp),%eax
testl %eax,%eax
je .L3
addl $-8,%esp
decl %eax
pushl %eax
pushl %edx
call add__Fii
incl %eax
jmp .L175
.p2align 4,,7
.L3:
movl %edx,%eax
.L175:
movl %ebp,%esp
popl %ebp
ret
int add1 (int a, int b)
{
while (b != 0)
++ a, -- b;
return a;
}
add1__Fii:
.LFB3:
pushl %ebp
movl %esp,%ebp
movl 8(%ebp),%eax
movl 12(%ebp),%edx
testl %edx,%edx
je .L7
.p2align 4,,7
.L8:
incl %eax
decl %edx
jnz .L8
.L7:
movl %ebp,%esp
popl %ebp
ret
> А вот тебе и мой любимый пример из "больших" финансовых приложений: если у
> тебя есть функция printDoc(...), абсолютно правильно печатающая документ, то из
> этого отнють не следует, что ты можешь написать for (int i=0; i<N; i++)
> printDoc(...), т.к. для N порядка десятков тысяч "просто корректно работающего
> кода" становится недостаточно, т.к. заранее известно, что печать всех выходных
> форм должна укладываться в разумное время.
Ну бывают в жизни огорчения. Но сначала-то надо, чтобы она "просто
корректно работала". К тому же - там же все это принтером и сеткой
ограничивается. Язык-то тут при чем?
Вообще-то - это типичная проблема real-time, но там обычно все гораздо
сложнее. Но подход к этим делам в принципе тоже намечается. По крайней
мере разумно выглядящие опыты с системами типов, дающими гарантированные
верхние оценки потребных ресурсов уже есть.
> > В Haskell подобный эффект достигается при помощи монад, но это труднее
> > объяснить "на пальцах". То есть проблема довольно давно решена.
> Ты не находишь немного странным то, что такая вполне прямая и естественная
> штука как вызов функции, имеющей побочный эффект (например выводящей что-то на
> экран или читающей с клавиатуры) на каком-то языке требует совершенно
> нетривиальных решений, не объясняемых "на пальцах"?
Не нахожу. Равно как не нахожу ничего странного, в том, что топология
гораздо более удобный подход к матану, чем вполне "прямая и
естественная" методика "эпсилон-дельта".
> Ну и пускай на этом языке что-то узкое и абстрактное становится проще -- зачем
> одновременно делать сложным простое? Какое-то шило на мыло получается. И я не
А зачем писать по возможности без goto? Затем, программа становится
сильно понятнее и количество ошибок сокращается в разы (и облегчается их
поиск). Тут тоже самое - когда известно, что семантика функции не зависит
от предыстории (точнее - что вся необходимая предыстория сосредоточена в
ее параметрах) - все резко проясняется.
> уверен, что в целом не проиграю от использования таких вычурных языков. Точнее,
> уверен, что в целом проиграю :)
Я совершенно точно уверен, что выигрываю. Два-три раза по времени на
собственно написание и еще довольно много - при отладке. Освободившееся
время можно потратить на улучшение быстродействия более интеллектуальными
способами, чем мелкое хакерство на С.
PS: На самом деле ты скорее всего все-таки именно оценивашь эффективность ML
не по тем образцам, по которым его надо оценивать. Это язык примерно
стольже просто реализуемый, как Pascal. По эффективности - вполне
сравним с С++, когда С++ используется не как С. Причем есть очень
приятная фишка, аналоги что "продвинутых" конструкций С++ обходятся
в ML существенно дешевле.
Антон
Sergey P. Derevyago
> > За большинство согласен, но не все. И тормоза лежат, как правило, в работе с
> > БД -- это да. И вот эту самую работу с БД нужно ускорять как можно больше и
> > сильнее. Возьмешься писать прослойку между прикладным уровнем и используемой БД
> > на ML? :)
> За деньги - вполне.
> Иногда даже без денег хочется - там все очень красиво
> и просто получается. А скорость - да все равно все SQL-сервер пожрет.
Нет, не пожрет. Ты когда программы профилировал, какие действия были самыми
часто используемыми? В тех "финансовых" лидировали пересылки/преобразования
байт туда-сюда. Вряд ли ты меня убедишь, что ML в этом силен.
> А
> так хоть есть шансы какой-то интеллект поверх приладить (ну типа -
> запросы пооптимизировать, результат в каком-то удобном виде
> сформировать). На плюсах программирование такого интеллекта обычно
> превращается в подвиг, а тут - упражнение на денек-другой.
Не надо перегибать, pls, а то становится неприятно читать. Ну прям как тех
горячих пионэров :(
> > А будет, для "быдла неразумного" -- тупые мягкие столовые ножи, а вот какие
> > скальпели выберут профессионалы -- это еще вопрос. И в этом вопросе мнение
> > большинства меня не интересует, т.к. также как и в любой другой человеческой
> > деятельности, большинство являет собой серое некомпетентное стадо, пришедшее
> > срубить деньжат не важно на чем. Так было и так будет.
> Я склонен думать, что к "быдлу неразумному" будут относиться как раз
> поклонники С++.
Да, незавидна их участь ;)
> Ну как сейчас есть вполне приличный и денежный рынок
> программирования на COBOL.
Ну, если обо мне, то я уже давно дорос до того уровня, когда сам выбираю чем
мне заниматься, и за COBOL, FORTRAN и т.д. никогда не сяду, т.к. нервы дороже
:) Ну а если кто-то готов стелиться под моду дня, то это его личный выбор, и, к
слову сказать, на большом промежутке времени такое поведение неоптимально.
> > > > Подходишь. Об эффективности конструкций ты судишь по С/С++. В том же ML -
> > > вызов фукнции в разы дешевле,
> > Ой, Антон! Не надо так вот, хорошо?
> Я же примерчик приводил: разница в 6 раз в пользу ML (просто add - он совершенно
> в обычном смысле рекурсивный).
Я не вижу никаких причин, почему вызов функции в С/С++ должен быть в разы
дороже чем в ML.
> > Ну разбили, наплодили вместо блоков функции... И шо, ничего не потеряли? Может
> > оно, конечно, по смыслу и то же самое, да только вот _эффективность_ работы от
> > появления ненужных вызовов функций может очень сильно измениться. И явно не
> > ускориться.
> Так никаких вызовов там и не будет - ну давай опыт поставим: ты
> какой-нибудь маленький пример нарисуешь, я его перепишу по
> вышеназванному рецепту и пришлю вместе с ассемблерным порождением
> (главное требование - чтобы порождение у С-шной версии не было слишком
> длинным, тогда и аналог будет обозрим.
Маленькие примеры -- это неправильно (посмотри сколь прекрасно быстродействие
жабы на "малых примерах" ;) Меня всегда интересовала разработка и поддержка
чего-то большого и серьезного. И я знаю по личному опыту, что С++ в "большом и
серьезном" чаще всего оказывается наилучшей альтернативой.
> > А вот тебе и мой любимый пример из "больших" финансовых приложений: если у
> > тебя есть функция printDoc(...), абсолютно правильно печатающая документ, то из
> > этого отнють не следует, что ты можешь написать for (int i=0; i<N; i++)
> > printDoc(...), т.к. для N порядка десятков тысяч "просто корректно работающего
> > кода" становится недостаточно, т.к. заранее известно, что печать всех выходных
> > форм должна укладываться в разумное время.
> Ну бывают в жизни огорчения. Но сначала-то надо, чтобы она "просто
> корректно работала". К тому же - там же все это принтером и сеткой
> ограничивается.
Гы! Собственно печать составляет o-малое от формирования plain текстовых
файлов для печати. Основная тяжесть ложится на сбор, группировку и обсчет
данных.
> > Ты не находишь немного странным то, что такая вполне прямая и естественная
> > штука как вызов функции, имеющей побочный эффект (например выводящей что-то на
> > экран или читающей с клавиатуры) на каком-то языке требует совершенно
> > нетривиальных решений, не объясняемых "на пальцах"?
> Не нахожу. Равно как не нахожу ничего странного, в том, что топология
> гораздо более удобный подход к матану, чем вполне "прямая и
> естественная" методика "эпсилон-дельта".
Давай не будем на эту тему, ОК? Я просто скажу, что закончил мех-мат по
кафедре ФАН и вполне представляю данную тему для того, чтобы не согласиться с
твоим утверждением "об удобстве подхода".
> > Ну и пускай на этом языке что-то узкое и абстрактное становится проще -- зачем
> > одновременно делать сложным простое? Какое-то шило на мыло получается. И я не
> А зачем писать по возможности без goto?
Совершенно не за чем. Здравая идея, заложенная в фразу "программы без goto"
становится идиотизмом у руках тех, кто понимает все слишком буквально.
Правильный девиз: "Не используйте goto там, где существуют более уместные
альтернативы". А они существуют далеко не везде.
> Затем, программа становится
> сильно понятнее и количество ошибок сокращается в разы (и облегчается их
> поиск). Тут тоже самое - когда известно, что семантика функции не зависит
> от предыстории (точнее - что вся необходимая предыстория сосредоточена в
> ее параметрах) - все резко проясняется.
В плане оптимизации и ясности кода, не всегда уместно гонять через глубокие
вызовы данные для изменения в самом глубоком месте. Надеюсь, что это очевидно.
> > уверен, что в целом не проиграю от использования таких вычурных языков. Точнее,
> > уверен, что в целом проиграю :)
> Я совершенно точно уверен, что выигрываю. Два-три раза по времени на
> собственно написание и еще довольно много - при отладке. Освободившееся
> время можно потратить на улучшение быстродействия более интеллектуальными
> способами, чем мелкое хакерство на С.
Я искренне за тебя рад :)
Anton Moscal
> > Иногда даже без денег хочется - там все очень красиво
> > и просто получается. А скорость - да все равно все SQL-сервер пожрет.
> Нет, не пожрет. Ты когда программы профилировал, какие действия были самыми
> часто используемыми? В тех "финансовых" лидировали пересылки/преобразования
> байт туда-сюда. Вряд ли ты меня убедишь, что ML в этом силен.
В чем именно - преобразования - так там примерно все тоже самое. А
пересылки - это как раз самое забавное: в ML присваивание - это просто
присваивание указателей (если значение сложнее целого). При этом GC
освобождает от счетчиков ссылок или необходимости копировать
динамическу структуру только для того, чтобы потом деструктор ее правильно
убил. И память, кстати, экономится.
В некоторых случаях наличие лишних косвенностей портит скорость, но обычно
- наоборот. Я, посмотрев на порождение ML начал и на С++ так писать, в тех
случаях, когда можно.
> > так хоть есть шансы какой-то интеллект поверх приладить (ну типа -
> > запросы пооптимизировать, результат в каком-то удобном виде
> > сформировать). На плюсах программирование такого интеллекта обычно
> > превращается в подвиг, а тут - упражнение на денек-другой.
> Не надо перегибать, pls, а то становится неприятно читать. Ну прям как тех
> горячих пионэров :(
Я не перегибаю. Это правда. Работать на С++ с динамическими структурами
данных - это как в какой-то вязкой жидкости плавать. Можно сделать почти
все. И почти все - с изрядными усилиями. А любой нетривиальный интеллект
такого рода требует всяких промежуточных представлений и прочая.
И рекурсивных алгоритмов, кстати, тоже.
Вообще - то, что проектирование структур данных при программировании на
С/С++ является важной и сложной проблемой - это маразм. Это именно язык
плохой. Чтобы описать обычное дерево (например представление того-же
запроса) на С++ надо написать в 10-20 раз больше, чем на ML. Неоднократно
проверял.
Ну и соотвественно - 1000 строк кода можно легко переделать при
необходимости, а 10000-20000 - уже десять раз подумаешь прежде чего-то
менять.
> > > А будет, для "быдла неразумного" -- тупые мягкие столовые ножи, а вот какие
> > > скальпели выберут профессионалы -- это еще вопрос. И в этом вопросе мнение
> > > большинства меня не интересует, т.к. также как и в любой другой человеческой
> > > деятельности, большинство являет собой серое некомпетентное стадо, пришедшее
> > > срубить деньжат не важно на чем. Так было и так будет.
> > Я склонен думать, что к "быдлу неразумному" будут относиться как раз
> > поклонники С++.
> Да, незавидна их участь ;)
>
> > Ну как сейчас есть вполне приличный и денежный рынок
> > программирования на COBOL.
> Ну, если обо мне, то я уже давно дорос до того уровня, когда сам выбираю чем
> мне заниматься, и за COBOL, FORTRAN и т.д. никогда не сяду, т.к. нервы дороже
> :) Ну а если кто-то готов стелиться под моду дня, то это его личный выбор, и, к
Ну вот у меня примерно тоже отношение к С++.
> > Я же примерчик приводил: разница в 6 раз в пользу ML (просто add - он совершенно
> > в обычном смысле рекурсивный).
> Я не вижу никаких причин, почему вызов функции в С/С++ должен быть в разы
> дороже чем в ML.
А ты тот примерчик-то посмотри. Соглашения о связях в С хреновые.
> > (главное требование - чтобы порождение у С-шной версии не было слишком
> > длинным, тогда и аналог будет обозрим.
> Маленькие примеры -- это неправильно (посмотри сколь прекрасно быстродействие
> жабы на "малых примерах" ;) Меня всегда интересовала разработка и поддержка
В больших примерах - тоже самое. Компилятор O'Caml - 90000 строк. Я его
код смотрел. Это не Java, тут транслятор ничего не оптимизирует (даже
тривиальных вещей - типа тех же переходо). Только распрелелние регистров и
минимальный inlining. И все равно - код хороший.
> чего-то большого и серьезного. И я знаю по личному опыту, что С++ в "большом и
> серьезном" чаще всего оказывается наилучшей альтернативой.
Пока - видимо еще да (хотя интересный вопрос - а на чем ты еще
пробовал писать "что-то" серьезное?). Хотя я боюсь, что жаба и С# - уже
лучше. Именно тем, что при некоторой дерьмовости языка (можно бы и лучше
сделать), имеют вполне нормальные библиотеки и поддержку производителей. И
сильно превосходят С++ по удобству.
> Гы! Собственно печать составляет o-малое от формирования plain текстовых
> файлов для печати. Основная тяжесть ложится на сбор, группировку и обсчет
> данных.
Извини - не верю. Это 100% признак, что у вас там в консерватории что-то
подправить надо. Структуры данных реорганизовать или алгоритмы
более подходящие подобрать. А для этого надо не профайлером оптимизировать
пересылки (это, кстати, само по себе - симптом, не могут в правильно
организованной программе пересылки занимать большую часть времени), а
что-то более интеллектуальное препринимать. А большую программу на С++
переделать крайне трудно - это я по своему опыту знаю.
> > > Ну и пускай на этом языке что-то узкое и абстрактное становится проще -- зачем
> > > одновременно делать сложным простое? Какое-то шило на мыло получается. И я не
> > А зачем писать по возможности без goto?
> Совершенно не за чем. Здравая идея, заложенная в фразу "программы без goto"
> становится идиотизмом у руках тех, кто понимает все слишком буквально.
> Правильный девиз: "Не используйте goto там, где существуют более уместные
> альтернативы". А они существуют далеко не везде.
В принципе примерно тоже самое верно и про побочные эффекты. Но есть еще
одна сторона - полный отказ от goto сильно улучшает жизнь транслятору, а
это выливается во вполне практические преимущества. Побочные эффекты -
аналогично.
> > от предыстории (точнее - что вся необходимая предыстория сосредоточена в
> > ее параметрах) - все резко проясняется.
> В плане оптимизации и ясности кода, не всегда уместно гонять через глубокие
> вызовы данные для изменения в самом глубоком месте. Надеюсь, что это очевидно.
Ну ты бы с предметом все-таки ознакомился. Там все не вполне так плохо. То
есть реально проблем не больше, чем от полного запрета на goto: иногда
возникают неудобства, но редко. Только не надо пытаться писать как
на С.
Но дело в том, что удобства-то тоже возникают. И пожалуй - перевешивают.
Антон
Sergey P. Derevyago
> > мне заниматься, и за COBOL, FORTRAN и т.д. никогда не сяду, т.к. нервы дороже
> > :) Ну а если кто-то готов стелиться под моду дня, то это его личный выбор, и, к
> Ну вот у меня примерно тоже отношение к С++.
Serge Shikov
>
> > расширен в плане прямой поддержки некоторых аспектов функционального
> > программирования, т.к. это _реально_ _нужно_.
>
> Это невозможно. Да и не нужно. С++ умирает. Что будет - вопрос сложный,
> но точно - не он. Я вот сейчас по работе пишу на C# - он мне нравится меньше
> ML, но общее ощущение похожее - на нем можно программировать, а не бороться
> с всякой фигней.
машину иметь, чтобы имело смысл?
Vitaly Lugovsky
> >> Практика показывает, что без ошибок человек работать не может.
> >> И, похоже, это принципиально.
> VL> Это гнилая, ламерская практика. У не-ламеров ошибок действительно не
> VL> бывает.
> Смелое утверждение. Можно согласиться с тем, что кто-то ошибается
> чаще, кто-то - реже, но чтобы нашелся человек, который за всю свою
> зрелую профессиональную деятельность не ошибся HИ РАЗУ...
Люди ошибаются. Hо не-ламер тем и отличается от ламера, что может эти
ошибки обнаружить и исправить, не внося новых ошибок.
> В тривиальных случаях человек ошибается от монотонности. Как
> бы он сосредоточенно не молотил по клавишам, изредка, но промахнется.
> В тех случаях, когда это "чревато", ставят защиту от промахов.
Это и за ошибку не считаем - отловить такое дело вовсе не проблема.
> В сложных, творческих ситуациях возникают ошибки другого плана -
> когда интуиция опережает логику, или когда при работе над
> общим планом упускаются некоторые детали.
Вот вот. Я же выступаю против применения интуиции ВООБЩЕ. Все должно
делаться строго, заформализованно. Hельзя давать волю подсознанию - оно
такой бред иногда способно выдать, что и никакого ЛСД не требуется.
> В общем случае, когда человек "зажат" невозможностью ошибаться
> (допустим, ему сказали - тестировать твою программу не будем,
> сразу установим в систему защиты атомного реактора :) ,
> производительность его труда сильно снизится.
> И вообще, отказываясь от автоматизированного тестирования, ты
> становишься "тестером" сам, тем самым отвлекая значительные ресурсы
> "био-процессора" - снижая свою производительность.
Я не отказываюсь от тестирования. Я отказываюсь от итерационного дебага,
основанного на тестировании. Тесты же должны выводиться формально, из
задекларированных свойств интерфейсов модулей, и реализовываться в виде
АССЕРТОВ.
Vitaly Lugovsky
> >> Полгода думаешь, потом месяц пишешь - получаешь готовый продукт?!
> >> Hе бывает так.
> VL> Еще как бывает. Пишешь спецификации, по ним - реализацию, потом
> VL> везде, где только можно, доказываешь соответствие реализации спекам,
> VL> а где нельзя ассертишь требования спецификации - и все, радуйся жизни.
> А потом спецификации меняются и перед началом очередной итерации ты пишешь в
> su.softw: "Все ВЫ @#$%! А жизнь - ГАВHО!"
А вот тут, при правильном проектировании, придется менять весьма мало
чего, и проще переписать несколько мелких модулей с нуля, чем перелопачивать
по живому крупные модули.
Ilya B. Yarushkin
больно его все
применения в subj
> > > > _совершенно_, да и, судя по всему, никогда и не предназначался.
хватает, но
> > > это ортогонально к языку.
> > А вот программеру-юзеру языка совершенно ортогонально, что язык хороший,
если
> > нет хороших библиотек. И, в принципе, он прав.
> > обширной библиотеки с первым релизом С++. И ведь действительно,
отсутствие
> > хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++
и его
> > возможности. И наоборот: присутствие готовых библиотек и массированное
вранье
> > исказило (и искажает) взгляд трудящихся на Жабу ;)
>
> То есть ты под "библиотеками" имеешь в виду STL и около (я-то имел в виду
> это-то все есть: списки есть, массивы есть, очереди есть, hash-таблицы
> есть, map'ы и множества - тоже есть. Строки есть. Причем в отличие от С++,
> где создание STL было великим подвигом - тут все это пишется с полпинка и
> очередь с приоритетами, которой в STL нету), то 100-150 строк (час-два
> работы) и золотой ключик твой.
Подвиг состоялся и теперь приходится бороться ещё и с STL в различных её
воплощениях (реализациях). ИМХО в случае C++ (и подобных языков) было бы
достаточно просто изначально включить в _язык_ на уровне встроенных типов
стандартные полиморфные контейнеры и алгоритмы их обработки (специфицировав
требования по скоростным характеристикам). К слову сказать их совсем не
много (кроме экзотики). Чтоже касается STL в сравнении с возможностями FP то
тут и говорить нечего - то что на ml/lisp/haskell пишется в пару строк
изящного и прозрачного кода на STL делается через... ну вообщем template-ы -
все знают как они реализованы на практике даже в лучших C++ компиляторах...
Отсутствие Win API, MFC, openGL e.t.c. конечно убивает - до сих пор удивлён
что не нашлось энтузиаста(ов) совершивших бы этот подвиг (благо что ML к
примеру в сырцах даром раздаётся) - видимо все они живут в unix-ах и всем
довольны...
> > > Ну еще одну знаю - real-time на языке со
> > > сборкой мусора программировать не стоит (но это вообще очень
> > > специфическое применение). А еще чего?
> > Дык эть итерации, т.к. делать _все_ через рекурсию выходит
неправдоподобно
> > прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но
ведь "не
> > боги горшки обжигают"...
>
> По поводу рекурсии ты просто не прав: не надо подходить к другим языкам с
мерками С.
> Кроме того, существует такая вещь, как tail recursion, которая вообще
> реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего
нет:
Любопытно насколько теоритически возможно раскрутить любую (нетолько tail)
рекурсию...
ну пусть не совсем, но скажем 0-1 порядков...
Kind Regards
Ilya aka Warlock
Vitaly Lugovsky
>> Hу еще одну знаю - real-time на языке со
>> сборкой мусора программировать не стоит (но это вообще очень
>> специфическое применение). А еще чего?
> Дык эть итерации, т.к. делать _все_ через рекурсию выходит неправдоподобно
> прожорливо, чтобы иметь реальный смысл. Да, "рекурсия божественна", но ведь
> "не
> боги горшки обжигают"...
А про proper tail recursion мсье не слышал?
Vitaly Lugovsky
> >> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
> >> VL> ДОКАЗАHHЫЕ системы.
> >> Бывают. Какую долю рынка они занимают?
> VL> Естественно совершенно незначительную - ибо рынок делают ламеры, коих
> VL> много. А доказывать код умеют единицы.
> Тогда какой толк от этих твоих песнопений? Или ты действительно хочешь, чтобы
> тебя лишили возможности пользоваться _всем_ софтом, написанным "ламерами"?
Hет, я хочу, чтобы требования потребителей выросли, чтобы людям надоело
жрать дерьмо, и ламерам, для удовлетворения новых требований рынка, пришлось
бы подучиться.
> VL> Дык для модульной системы можно постановку менять по ходу дела с малой
> VL> кровью.
> А толку?
А то и толку, что сами модули остаются практически неизменными, хорошо
запроектированными и с высокой степенью вероятности безглючными.
Vitaly Lugovsky
>> > Вот, например, Страуструп самой серьезной своей ошибкой считает
>> > невыпуск
>> > обширной библиотеки с первым релизом С++. И ведь действительно, отсутствие
>> > хороших готовых библиотек чрезвычайно исказило взгляд трудящихся на С++ и
>> > его
>> > возможности. И наоборот: присутствие готовых библиотек и массированное
>> > вранье
>> > исказило (и искажает) взгляд трудящихся на Жабу ;)
>> То есть ты под "библиотеками" имеешь в виду STL и около (я-то имел в виду
>> всякие интерфейсы с Win API, MFC, openGL, GTK, базами данных etc etc).
> Я имел ввиду и STL и DBMS API и т.д. и т.п. Т.е. все то, что нужно,
> например,
> для написания финансовых приложений.
При чем тут STL? STL - жуткое позорище по сравнению с библиотекой любого
функционального языка - там это родное, а в C++ - чужеродное. Биндинги
разнообразных DBMS - тоже в количестве немерянном присутствуют. Да и
написать - просто, как два байта переслать. Я биндинги oci8 для ocaml за
несколько дней исключительно в свободное время слабал.
> Полностью согласен с тем, что добавленные в С++ шаблоны люди стали
> использовать гораздо шире, чем оно планировалось. Поэтому написание STL с
> использованием идей функционального программирования, не поддерживаемого С++,
> явилось большим и трудным делом. Кстати, я абсолютно уверен, что С++ будет
> расширен в плане прямой поддержки некоторых аспектов функционального
> программирования, т.к. это _реально_ _нужно_.
Hо это практически нереализуемо. В C++ нет и не будет GC. Hе будет
корректной отработки хвостовой рекурсии. И, совершенно понятно, не будет
сколько нибудь разумной системы типов.
>> Кроме того, существует такая вещь, как tail recursion, которая вообще
>> реализуется как переход. Вот простенький тестик, где кроме рекурсии ничего
>> нет:
> Простенький тестик злобно скипнут, т.к. tail recursion -- это редкий и
> малоинтересный случай. А "все остальные" случаи будут приводить в ML к
> рекурсивной обработке с неразумным пожиранием ресурсов.
Hо ведь не приводят, что характерно. Смотри внимательнее, как там устроен
рантайм. Особенно интересен bytecode runtime, так как он свободен от
недостатков реальных аппаратных платформ.
> Антон, ну не надо теории разводить, хорошо? Программу без побочных эффектов
> можно вообще не запускать, т.к. в конечном итоге она ничего не делает. А если
> она что-то делает, то "побочные эффекты" где-то явно есть ;)
Как это ничего не делает? А конечный результат? output=program(input), и
этот самый output мы и хотим получить.
Vitaly Lugovsky
>> Иногда даже без денег хочется - там все очень красиво
>> и просто получается. А скорость - да все равно все SQL-сервер пожрет.
> Hет, не пожрет. Ты когда программы профилировал, какие действия были самыми
> часто используемыми? В тех "финансовых" лидировали пересылки/преобразования
> байт туда-сюда. Вряд ли ты меня убедишь, что ML в этом силен.
А ты уверен, что тебе придется в ML их вообще туда-сюда пересылать, и, тем
более, преобразовывать? Что вообще есть "финансовые программы"?
>> А
>> так хоть есть шансы какой-то интеллект поверх приладить (ну типа -
>> запросы пооптимизировать, результат в каком-то удобном виде
>> сформировать). Hа плюсах программирование такого интеллекта обычно
>> превращается в подвиг, а тут - упражнение на денек-другой.
> Hе надо перегибать, pls, а то становится неприятно читать. Hу прям как тех
> горячих пионэров :(
Это не перегибы. Посмотри на объем BC4J. И ведь это не плюсы, а Жаба. У
меня же аналогичный интеллект гораздо короче получается...
> Hу, если обо мне, то я уже давно дорос до того уровня, когда сам выбираю чем
> мне заниматься, и за COBOL, FORTRAN и т.д. никогда не сяду, т.к. нервы дороже
> :) Hу а если кто-то готов стелиться под моду дня, то это его личный выбор, и,
> к
> слову сказать, на большом промежутке времени такое поведение неоптимально.
А зачем тогда пишешь "финансовые приложения"? Всегда думал, что это задача
для обезьянок-кодеров, а не для творческой, свободной личности...
>> Я же примерчик приводил: разница в 6 раз в пользу ML (просто add - он
>> совершенно
>> в обычном смысле рекурсивный).
> Я не вижу никаких причин, почему вызов функции в С/С++ должен быть в разы
> дороже чем в ML.
Hу так это твои трудности. Если уж тебе, свободной да творческой личности,
лихо лабающей финансы на ЦэПеПе, так сильно лениво почитать литературу по
теории компиляции в приложении к функциональным языкам - то и бисер тут
перед тобой метать смысла нет.
> Маленькие примеры -- это неправильно (посмотри сколь прекрасно
> быстродействие
> жабы на "малых примерах" ;) Меня всегда интересовала разработка и поддержка
> чего-то большого и серьезного. И я знаю по личному опыту, что С++ в "большом
> и
> серьезном" чаще всего оказывается наилучшей альтернативой.
В данном случае от тебя всего лишь требовалось понять, что не всегда вызов
функции это вызов функции. Ты же зачем-то перескочил в совсем другую
степь... Смешно. Все адепты C++ исповедуют такую же технологию спора? Или ты -
уникум?
> Гы! Собственно печать составляет o-малое от формирования plain текстовых
> файлов для печати. Основная тяжесть ложится на сбор, группировку и обсчет
> данных.
Всю сознательную жизнь генережкой отчетов занимаюсь - никаких проблем не
встречал. Может, в консерватории что-то не так? Может, база хреново
спроектирована? Может, заместо парсера шаблона, по коему отчет слабать, туева
хуча
C++-ного кода на все малейшие чихи понаписана?
>> Затем, программа становится
>> сильно понятнее и количество ошибок сокращается в разы (и облегчается их
>> поиск). Тут тоже самое - когда известно, что семантика функции не зависит
>> от предыстории (точнее - что вся необходимая предыстория сосредоточена в
>> ее параметрах) - все резко проясняется.
> В плане оптимизации и ясности кода, не всегда уместно гонять через глубокие
> вызовы данные для изменения в самом глубоком месте. Hадеюсь, что это
> очевидно.
А их и не надо гонять. RTFM, в конце концов!
Vitaly Lugovsky
>> Для достаточно модульной архитектуры изменения требований не страшны.
>> Главное, чтобы сами модули были надежными.
> Главное чтобы функции модулей были выбраны верно. А это далеко не
> тривиально, и доказательству боюсь не поддается.
Когда модули весьма мелкие, и нет между ними лишних зависимостей - то и
переписать при изменении требований не жалко несколько модулей.
>> TeX - слишком простой, и по этой причине вовсе немодульный. Его проще
>> с нуля переписать.
> А, вот именно. Т.е. слишком простую программу Кнут написал без ошибок, и
> ее при этом проще переписать с нуля, чем что-то изменить. Это что, разве
> хорошо? Я тоже так умею - для простых программ. А толку?
Дык и для сложных тоже можно. Только это времени и денег стоит.
Vitaly Lugovsky
>> Кстати ты объясни - что это за такие финансовые приложения, для которых
>> нужно выжимание всех соков из процессора. Большинство известных мне вообще
>> можно хоть на перл'е программировать - ничего не изменится: все пожрет гуй
>> и базы данных.
>
> За большинство согласен, но не все. И тормоза лежат, как правило, в работе с
> БД -- это да. И вот эту самую работу с БД нужно ускорять как можно больше и
> сильнее. Возьмешься писать прослойку между прикладным уровнем и используемой
> БД
> на ML? :)
Впечатлившись от использования BC4J, я удумал написать аналог для ML.
Вроде бы пока на трудности не натолкнулся - просто дело медленно идет, ибо
сей проект для меня далеко не основной, а так, игрушка. В использовании эта
библиотека будет гораздо удобнее, чем BC4J.
>> > расширен в плане прямой поддержки некоторых аспектов функционального
>> > программирования, т.к. это _реально_ _нужно_.
>> Это невозможно. Да и не нужно. С++ умирает.
> Что, правда?! Ах ты боже мой! Я сейчас безутешно заплачу :~(
Дык ведь так и есть. Умирает. Я - так и вовсе не понимаю, на фига он
нужен...
>> Подходишь. Об эффективности конструкций ты судишь по С/С++. В том же ML -
>> вызов фукнции в разы дешевле,
> Ой, Антон! Hе надо так вот, хорошо?
С чего бы это не надо? А поRTFM-ить про рантайм? К примеру, " The ZINC
experiment" почитать, там вся эта философия разжевана.
> Hу разбили, наплодили вместо блоков функции... И шо, ничего не потеряли?
> Может
> оно, конечно, по смыслу и то же самое, да только вот _эффективность_ работы
> от
> появления ненужных вызовов функций может очень сильно измениться. И явно не
> ускориться.
HУ HЕТ ТАМ ВЫЗОВОВ HИКАКИХ!!!
>> В Haskell подобный эффект достигается при помощи монад, но это труднее
>> объяснить "на пальцах". То есть проблема довольно давно решена.
> Ты не находишь немного странным то, что такая вполне прямая и естественная
> штука как вызов функции, имеющей побочный эффект (например выводящей что-то
> на
> экран или читающей с клавиатуры) на каком-то языке требует совершенно
> нетривиальных решений, не объясняемых "на пальцах"?
А что такого прямого и естественного в ФУHКЦИИ, изменяющей ВHЕШHИЙ МИР?!?
Да это вообще мистицизм какой-то, у меня вот и в голове даже не
укладывается. Сразу Спрег де Камп вспоминается, с его дипломированным
чародеем... Может, у тебя мышление не математическое, что для тебя такая
мистика кажется естественной?
Vitaly Lugovsky
> В больших примерах - тоже самое. Компилятор O'Caml - 90000 строк. Я его
> код смотрел. Это не Java, тут транслятор ничего не оптимизирует (даже
> тривиальных вещей - типа тех же переходо). Только распрелелние регистров и
> минимальный inlining. И все равно - код хороший.
Дык там оптимизация кой какая на уровне лямбда-выражений.
А уж из них код почти в тупую генерится... btw, давно тянет
написать JIT для байткодов - уж больно хорошие там перспективы
оптимизации. Пока ничего хорошего из этой затеи не вышло - сложно
ветвления предсказывать...
Alexey Mahotkin
IBY> Отсутствие Win API, MFC, openGL e.t.c. конечно убивает - до
IBY> сих пор удивлён что не нашлось энтузиаста(ов) совершивших бы
IBY> этот подвиг (благо что ML к примеру в сырцах даром раздаётся)
IBY> - видимо все они живут в unix-ах и всем довольны...
Интерфейс к OpenGL, at least:
http://caml.inria.fr/distrib/bazar-ocaml/lablgl-0.94.tar.gz
Hе использовал =)
Зачем делать "интерфейс к MFC"? :)
--alexm
Alexey Mahotkin
MF> Я даже интерпретатор С++ уже нашел - Cint, но это практически
MF> совсем не то.
Я знаю чуваков, которые делают виртуальную машину для C++ с гарантией
безопасности выполняемого на ней байт-кода.
Hу, в смысле они умеют транслировать современный C++ в специальный
байт-код.
--alexm
Vitaly Lugovsky
> Отсутствие Win API, MFC,
Кому это непортабельное позорище нужно?!? Юзаем нормальные тулкиты...
> openGL
Есть давно, по крайней мере для ocaml.
> e.t.c. конечно убивает - до сих пор удивлён
> что не нашлось энтузиаста(ов) совершивших бы этот подвиг (благо что ML к
> примеру в сырцах даром раздаётся) - видимо все они живут в unix-ах и всем
> довольны...
Да, на юнихах с библиотеками получше - ну дык их там и побольше будет.
Как правило портирование всего этого хозяйства с юниксов на вынь - не шибко
проблема. Разве что сейчас ocaml под cygwin треды не умеет, что обидно...
> Любопытно насколько теоритически возможно раскрутить любую (нетолько tail)
> рекурсию...
> ну пусть не совсем, но скажем 0-1 порядков...
Теоретически раскрутить можно вообще любую. Hо дорого.
Nikita V. Belenki
>> >> VL> И что в этом хорошего? Кстати, не всегда. Бывают очень большие
>> >> VL> ДОКАЗАHHЫЕ системы.
>> >> Бывают. Какую долю рынка они занимают?
>> VL> Естественно совершенно незначительную - ибо рынок делают ламеры,
>> VL> коих много. А доказывать код умеют единицы.
>> Тогда какой толк от этих твоих песнопений? Или ты действительно хочешь,
>> чтобы тебя лишили возможности пользоваться _всем_ софтом, написанным
>> "ламерами"?
VL> Hет, я хочу, чтобы требования потребителей выросли, чтобы людям надоело
VL> жрать дерьмо, и ламерам, для удовлетворения новых требований рынка,
VL> пришлось бы подучиться.
Так и запишем: отказываться от существующего на рынке софта ты не хочешь.
Тогда почему ты думаешь, что этого должны хотеть другие?
>> VL> Дык для модульной системы можно постановку менять по ходу дела с
>> VL> малой кровью.
>> А толку?
VL> А то и толку, что сами модули остаются практически неизменными, хорошо
VL> запроектированными и с высокой степенью вероятности безглючными.
Какая разница, какими будут _модули_, если глючность системы связяна с
глючностью постановки задачи?
Kit.
Sergey P. Derevyago
> SD> т.к. то, что является подвигом в ООП становится совершенно обычным
> SD> делом в generic programming,
> ^^^^^^^^^^^^^^^^^^ можно подробнее об этом? Что это такое?
Т.н. обобщенное программирование. В рамках С++ оно означает использование
шаблонов, т.е. полиморфизма времени компиляции.
> И особенно в контексте отквоченной фразы в сравнении с ООП ;)
О его сравнении с полиморфизмом времени выполнения можно, например, почитать у
Страуструпа, где он пишет об устройстве STL.
Alexander Krotoff
AM> On Fri, 16 Mar 2001, Alexander Krotoff wrote:
>> Любимый мой пример (ох сейчас побъют, слишком уж часто я его
>> поминаю, но с другой стороны на то он и любимый ;-) - поиск
>> максимально длинной повторяющейся подстроки в строке
>> (из Бентли).
>>
>> AM> А я дам себе труд на ML написать (причем способ объехать ML раза в три я
>> AM> знаю).
>>
>> Я не помню давал ли ты решение на ML когда мы ее в c-cpp
AM> Возможно тогда меня там не было. Не помню уже. Как я понимаю -
AM> повторяющиеся подстроки могут перекрываться? И что является
Да.
AM> типовым тестовым примером? Короткий ответ в длинной строке или длинный
AM> ответ в длинной строке?
Просто нужно красивое решение. Типовой тест - обычная книга.
Бентли ссылался на "Одиссею".
--
Успехов,
Саша.
Sergey P. Derevyago
> > -----------------------------------8<-----------------------------------
> > extern void f() throw();
> >
> > int main()
> > {
> > f();
> > }
> > -----------------------------------8<-----------------------------------
> > void f()
> > {
> > throw "Opa!";
> > }
> > -----------------------------------8<-----------------------------------
> > А если хватит мозгов, то заодно и подумай, могло ли это произойти, если бы
> > спецификация возбуждаемых исключений входила в тип функции.
>
> Трудно что ли взять стандарт и почитать, вместо того, чтобы фантазировать:
>
> ______________________________________________________________________
> 15.4 Exception specifications [except.spec]
>
> 2 If any declaration of a function has an exception-specification, all
> declarations, including the definition and an explicit specialization,
> of that function shall have an exception-specification with the same
> set of type-ids. If any declaration of a pointer to function, refer-
> ence to function, or pointer to member function has an exception-spec-
> ification, all occurrences of that declaration shall have an excep-
> tion-specification with the same set of type-ids. In an explicit
>
> То есть это просто транслятор недоделаный. Так это родовая черта С++ -
> трансляторы никогда не соотвествуют столь мелким деталям. GCC вообще не
> понимает exception specs на указателях (хотя должен), а VC 6.0 -
> понимает, но не делает никаких проверок даже в пределах одной фукнции,
> несмотря на явные и недвусмысленные указания стандарта (с примерами)
Если умеешь читать, то загляни в пункт 15.4 p.12: An exception-specification
is not considered part of a function's type.
А если умеешь думать, то подумай почему в приведенном тобой пункте 2 (кстати,
ты из него выбросил самое интересное. Странно да? ;) в самом конце написано: A
diagnostic is required only if the sets of type-ids are different within a
single translation unit.
Еще раз: я утверждаю, что приведенный мной пример будет без ошибок
компилироваться и линковаться на всех standard-conforming реализациях, потому
что так и было задумано. А для дураков советую еще раз попытаться понять, что
именно написано в http://cpp3.virtualave.net/cpp3comm/431 и не пытаться
передергивать факты.
> > Так ведь это еще далеко не все, мой недалекий друг. Если немного подумать в
> > голову, то можно придти к выводу, что, например, создающая массив объектов
> > функция, вызывающая соответствующий конструктор, обязана сохранять в
> > определенном месте (чаще всего стекового фрейма) количество созданных на данный
> Ты попробуй пример написать соответствующий твоим словам, у тебя не
> получится.
Читай thread "EH implementation" в c.l.c++.m Я там все обстоятельно разжевывал
и не хочу повторяться.
> ЗЫ: С++ - язык кривоватый, но не настолько. Некоторая внутренняя
> логичность ему все-таки присуща.
Ну хоть немного правды.
> ЗЗЫ: Знаешь, пожалуй ты все-таки в чистом виде ламер.
Думаю, что и так прекрасно видно кто здесь ламер и в каком виде.
Vitaly Lugovsky
> VL> Вот вот. Я же выступаю против применения интуиции ВООБЩЕ. Все должно
> VL> делаться строго, заформализованно. Hельзя давать волю подсознанию - оно
> VL> такой бред иногда способно выдать, что и никакого ЛСД не требуется.
> Эта твоя фраза показывает только, что ты не очень-то в курсе, как у
> человека голова работает. Почитай, что ли, Юнга для начала, потом с
> тобой уже можно будет разговаривать :-)
Юнг, в отличие от меня, ни фига не соображает, как у человека мозги
устроены. ;)
Vitaly Lugovsky
> VL> Странная у тебя практика. Можешь придумать более простую задачу, чем
> VL> написание компилятора? Там же все настолько заформализованно, что у
> VL> программиста нет никакой свободы действий, и, соответственно, никакой
> VL> возможности ошибиться.
> Так чего же они ошибаются то ?
Со злости, вестимо.
Vitaly Lugovsky
> VL> Hу так я же не делаю гуйню - так что тети Маши никогда мой софт
> VL> пользовать не будут.
> Ты думаешь, что промышленный софт отличается от академического только
> наличием
> удобного интерфейса?
Hет. Еще и разумностью и грамотностью заказчиков, и их способностью
формулировать требования. ;)
> VL> Правда, сейчас делаю бэк-энд для одного сайта, вот и посмотрим по
> VL> результатам - можно ли строгие методы применять в такой хреново
> VL> формализованной и постоянно меняющейся задаче.
> А велик ли бэк-энд?
Hе очень. Два человека всего в комманде. База на две сотни таблиц.
Только вот отчеты весьма сложной формы...
> VL> задача всегда изначально была строго заформализованна.
> Извини, но программировать задачи, поддающиеся полной формализации - это не
> более,
> чем упражнение для студентов.
Смотря какая сложность. Тот же мат. анализ - офигеть как заформализован -
а попробуй его запрограммировать. :)
У меня вот весьма заформализованная задача - клепать из моделей гипотезы и
подгонять по экспериментальным данным их параметры, после чего сравнивать и
ругаться. А сложностей там ну очень до фига...
Vitaly Lugovsky
> >> Так и запишем: отказываться от существующего на рынке софта ты не хочешь.
> >>
> >> Тогда почему ты думаешь, что этого должны хотеть другие?
> VL> Да хочу я отказаться, очень хочу! Дайте альтернативу!
> А ты готов за неё _платить_ столько, сколько она стоит?
Готов. О чем и кричу.
> >> Какая разница, какими будут _модули_, если глючность системы связяна с
> >> глючностью постановки задачи?
> VL> Такие глюки ловить определенно легче, чем глюки реализации.
> Почему ты так думаешь?
Потому, что, как правило, постановка задачи в голове худо-бедно умещается.
А вот сотни тысяч строк реализации - ни под какой наркотой в башку не
закатать.
Vitaly Lugovsky
>> >> Hо это практически нереализуемо. В C++ нет и не будет GC.
>> > Читай http://www.research.att.com/~bs/bs_faq.html#garbage-collection
>> Это не спасает.
> Спасает-не спасает, но по этой ссылке можно выйти на _реально_ работающий с
> некоторыми реализациями С++ GC, что опровергает утверждение о невозможности.
Обрати внимание на производительность таких GC.
>> Опять же - чужеродное решение. Hормальной модели памяти, с
>> нормальной сборкой мусора, на C++-ной системе типов ты не реализуешь. А
>> нетипизированная память - слишком дорого.
> Hе типизированная память С/С++ -- это объективная реальность и если
> попытаться
> гарантированно запретить преобразования указателей в void*, то никакого С уже
> не получится.
О чем я и говорю - из этого отстоя нормального языка уже не получится
никогда.
>> Требует, у него жесткие соглашения о вызовах.
> Hе мог бы ты мне пальцем указать тот пункт стандарта С++, где написано про
> "жесткие соглашения о вызовах" функций, имеющих обычный "С++" linkage. Как
> найдешь, так сразу же и поговорим ;)
Да, тут я прогнал. Если уж inline допускается, то и разворачивание
рекурсии не помешает. По крайней мере можно пары функций генерить - для
внешнего и для внутреннего вызова.
>> >> И, совершенно понятно, не будет сколько нибудь разумной системы типов.
>> > А что в твоем понимании есть "разумная система типов"? Давай
>> > поругаем,
>> > например, С++ на конкретных примерах с выдачей "правильных" альтернатив.
>> Система типов нужна хотя бы для высокопродуктивной работы с памятью. Такой
>> GC, как, к примеру, в OCaml (настоятельно рекомендую про него почитать, это
>> один из лучших алгоритмов), без типизированной памяти не изобразишь.
> Жесткая типизация памяти неприемлема для языков, обеспечивающих аналогичые С
> возможности по доступу к железу.
Это - маркетоидообразный бред. В порт байтик воткнуть можно и
строго-типизированно. От сишных указателей в программировании железа никакой
особой пользы не наблюдается.
> А если вообще про GC, то я не вижу для С++ в
> нем никакого смысла.
Если ты скажешь, что никогда лики не ловил, то я скажу, что ты - лжец.
Vitaly Lugovsky
> >> Я даже интерпретатор С++ уже нашел - Cint, но это практически совсем не
> VL> Тем более, нашел уже. И почему же совсем не то?
> 1. По заявлению авторов он реализует ISO C++ на 80%
Если взять суперпозицию основных компиляторов C++, то еще меньше общего
получится. Так что фигня.
> 2. Он предназначен для интерпретации скриптов. А мне а) эта функциональность
> не
> нужна и б) сомнительно, что он хорошо масштабируется для больших проектов
А чему там масштабироваться? Потеря производительности линейная для
интерпретации супротив компиляции.
> 3. Даже если бы было готовое средство в том виде, в котором я его представляю
> (полная интеграция с моим компилятором, GUI, набор инспекторов) - то я бы еще
> серьезно подумал, а стоит ли его использовать.
Тогда я не понял твоих запросов.
> VL> Гуевую глюкалку к нему присобачить - делов на копейку.
> Ты же сам говоришь, что серьезных UI не делал никогда. Почему же ты считаешь,
> что
> это дешевая операция?
Дык люди его для того и держат, чтоб быстро гуйню лабать.
http://root.cern.ch/
Vitaly Lugovsky
>> > IBY>Отсутствие Win API, MFC, openGL e.t.c. конечно убивает - до сих пор
>> > IBY>удивлён
>> Поаккуратней насчет всяких openGLов :)
>> http://www.cse.unsw.edu.au/~chak/haskell/gtk/ и где-то там еще
>> сейчас точнее не скажу, но что-то openglовское там было
>> (оно конечно не ML, но тоже)
> Для O'Caml тоже есть, но мне его очень квалифицирвоанно ругали. В основном
> по части издержек на стыке С-ML.
А можно эту ругань послушать? А то я интересу ради сравнил morph3d на Цэ и
на ocaml+lablgl - одинаковый FPS получается, с аппаратным ускорением.
Maxim Friedental
Vitaly Lugovsky wrote to Sergey P. Derevyago:
VL> Всю сознательную жизнь генережкой отчетов занимаюсь - никаких проблем не
VL> встречал. Может, в консерватории что-то не так? Может, база хреново
VL> спроектирована? Может, заместо парсера шаблона, по коему отчет слабать,
VL> туева хуча C++-ного кода на все малейшие чихи понаписана?
Возьми число запусков отчета в год на разных наборах данных и подели на число
изменений в год алгоритма собирания этого отчета. В известных мне "финансовых
приложениях" это отношение колеблется вокруг единицы. Обычно люди "не встречают
проблем с отчетами", когда этот коэффициент больше десятки.
See you.
Vitaly Lugovsky
>> > приложению.
>> Значит, БД спроектированна неверно. Да и преобразования форматов - задача
>> настолько тупая и примитивная, что жрать ресурсы никак не может - разве что
>> если очень постараться её извратить.
> Да что ты говоришь ;) Попробуй как-нибудь попреобразовывать внешне заданный
> BCD например в double.
Что это за задача такая, что эти преобразования оказываются bottleneck-ом?
>> > а их разработчики в ответ мямлят что-то вроде: "мы ж ее лавровый лист
>> > возить
>> > сделали, а вы, блин, 10 тон арматуры :(".
>> Hу ну, ты это мне порассказывай. И как я генерю целые книги из баз данных
>> в один присест? Просто ты не знаешь нормальных GC, небось, окромя тупого
>> подсчета ссылок и не видел ничего...
> Ой, спасибо, рассмешил старика ;))
Да, точно, когда аргументы кончаются, начинается идиотское хихиканье в
тряпочку.
Все, трепло пернатое, с тобой разговор закончен. Ты - упертый баран,
фанатик ЦэПэПэ, просто не желающий узнавать что либо новое, должно быть из
опасений за свою разлюбезную религию. Боишься веру потерять - ну и ладно,
носи розовые очки и прячь башку в песок каждый раз, как их с тебя сорвать
пытаются.
Vitaly Lugovsky
> PS: А слабо тебе привести не слишком большой пример, на коем достоинства
> С++ в смысле эффективности проявятся в полный рост? Законченную программу?
C++ или C? ;)
Vitaly Lugovsky
> >> А я говорил про тесты классов.
> VL> Hу так вот и делают - к каждому классу по утилитке с интерфейсом
> VL> коммандной строки. И поверх этого - система тестов.
> Можешь дать ссылки, в каких проектах так поступают?
Если честно - я только один видел. Hа Жабе писанный. Закрытый, не
посмотреть. Hо подход мне шибко понравился.
> VL> Кстати, такая метода помогает более правильно спроектировать иерархию
> VL> классов.
> Чем помогает?
Тем, что при написании тестов неизбежно формулируешь строго требования к
каждому классу, и можешь углядеть в процессе этого нелепости проектирования.