>>Страуструп взял статую Венеры Милосской и приделал ей руки.
>
>Вы очень высоко оцениваете художественный уровень языка C. Это метафора. Я Си тоже не считаю шедевром, но в своей нише он работает более-менее сносно.
>
>>Чистой воды костылизм. Если нужно было создать инструмент, работающий
>>с данными на абстрактном уровне, зачем было тащить за собой все
>>низкоуровневое наследие Си?
>
>Ровно потому, что над низкоуровневыми возможностями всегда очень хочется
>надстроить удобный абстрактный интерфейс. И C++, среди прочего, позволяет
>это сделать, не привлекая посторонних средств.
Проблема в том, что нельзя создать инструмент, которым одинаково хорошо можно было бы забивать сваи и подковывать блоху - что-то всегда будет за счет другого. Это не я придумал. Специализация, разделение труда и пресловутый Юникс-вей известны давно.
>[оверквотинг удален]
>нужно написать отдельный программный модуль на другом языке (C),
>да ещё в соответствии со специальными правилами, заданными спецификой
>применяемой языковой среды. Кто писал и сопровождал JNI-библиотеки,
>тот поймёт.
>
>Кстати, разумно и удобно организован процесс расширения низкоуровневыми
>алгоритмами разве что в Perl, который по моим наблюдениям процентов на
>50 состоит из таких боковых "костылей" - для обеспечения пристойной
>производительности.
>
Вот это-то как раз не "боковые костыли", а тот самый "низкий уровень", который выделен в отдельную прослойку, делающую только свои низкоуровневые дела, и делающую их хорошо. Это логично и правильно. А вот когда я мыслю объектами, строю сложные абстрактные структуры данных, но при этом должен заботиться о том, какой ширины у меня int, как бы мне не сорвать стек переполнением буфера, и как не забыть освободить выделенную память, - это уже костылизм!
Кстати, я как раз сейчас этим занимаюсь - пишу на Lua высокоуровневые скрипты, которые вызывают низкоуровненвые функции, обращающиеся к железу, которые пишу на Си. Легко и непринужденно. И мне страшно подумать, что бы было, если бы мне _все_это_ пришлось бы писать на Си++! Оо
>>В результате абстрактных структур данных мы так толком и не имеем,
>>и каждый фреимворк изобретает собственные велосипеды в виде классов
>>List, Matrix, Vector и т.д...
>
>Це еретики, которых правильно было бы отправить в топку.
>Самый правоверный набор примитивов - STL + boost, всё остальное - извращение.
>
Boost, в котором только одних типов указателей определено, наверное, с десяток? auto_ptr, linked_ptr, scoped_ptr, shared_ptr, smart_ptr, weak_ptr, intrusive_ptr, exception_ptr... Оо Это что, по-вашему, не костыли? Вот вы говорите, я не умею пользоваться возможностями Си++. А вы сами знаете как пользоваться всеми этими указателями? И ЗАЧЕМ знать все эти "возможности Си++", которые больше похожи на способы как победить компилятор? Лучше выбрать более адекватный инструмент сообразно поставленной задаче.
>>Термин "полноценные языки программирования" в вычислительной технике мне не знаком.
>
>Глупо сравнивать с одних и тех же позиций C++, M4 и SQL.
>Равно как и Haskell и Prolog.
>Изначально дискуссия шла об универсальных императивных языках программирования,
>иначе вести разговор о Java, C#, Perl, C++ и рекомом Go вообще
>бессмысленно.
>
Ну, наша с вами дискуссия началась с того, что я назвал С++ "костылем", и вашего возражения на это. Я сравниваю языки программирования с позиций задач, которые ставятся перед ними, и того, насколько эффективно эти задачи ими решаются.
>На самом деле у Perl и C++ сходная проблема - на них
>легко написать груду мусора
>вместо нормального кода. IMHO именно Perl - в своей области применения -
>должен был
>бы иметь жёсткий, обязательно многословный и безвариантный синтаксис. Чтобы написанное
>всегда однозначно читалось и не требовало выстраивать в голове конечный автомат
>для разбора очередной строки маловнятных символов.
Почему вы считаете, что для задач, которые решает Перл, нужен именно жесткий и многословный синтаксис? Не знаю, чем руководствовался Ларри Уолл в данном случае, но одной из его идей было - создать ЯП, максимально похожий на естественный язык. В естественных языках идиоматика и экспрессивность важнее точности описания, вот, он и решил перенести это на программирование... Насколько удачной была эта идея и ее реализация - спорить не буду. :)
