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