Re[12]: Направление прогресса
От: remark Россия http://www.1024cores.net/
Дата: 22.04.06 22:14
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, remark, Вы писали:



R>>Вобщем, что я хочу сказать. Есть вещи более простые, но с мменьшими возможностями (например, возьмёт логарифмическую линейку), а есть вещи более сложные, но с большими возможностями (например, возьмём компьютер). Конечно, человек, который 20 лет проработал с логарифмической линейкой, скажет про использование компьютера, что это сложно, что это не нужно, что это непонятно, что я так привык.

R>>Всё всегда идёт к усложнению и к большим возможностям. Это неизбежно. Но тут надо не отставать от жизни.
R>>Всегда существуют двигатели прогресса, которые исследуют новые возможности, потом облачают их более простую, понятную и пригодную для использованию форму. И после этого новые возможности становятся достоянием народа. Взять, например, современный автомобиль, штука офигеть какая сложная, зато возможностей сколько и использовать как просто. Всё. Мне пора в философию или о жизни

E>Ну вот примеров удачного использования исключений я видел много, а шаблонов -- мало. А вот идей Александреску -- ни одного случая

E>На самом деле код без исключений не такой уж и плохой обычно.

Ну это пока проект не особо большой. А когда проект переступает определённую черту, то коды ошибок начинают постепенно всасывать, причём со временем всё больше. имхо.


E>Но с исключениями немного лучше всё-таки. В том числе надёжнее.

E>Но надежнее он, кстати, не из-за исключений, а из-за scope guards, продуманной схемы владения объектами и другихарихитектурных достижений.
E>Собственно улучшают прогамму в основном они.
E>А уж когда ты их внедрил, то код с исключеними становится проще и понятнее

Но согласись, что усключения гораздо более сложная вещь, чем коды возврата, что для их применения надо знать больше, что код становится не таким очевидным (особенно для людей, знакомых с исключениями поверхностно).

E>А что и куда надо внедрить, чтобы стал проще и понятнее код с мультиметодами, например, я не знаю


Тут ты путаешь.
Есть понятие "что" (если на примере с исключениями, то "что" — это необходимость тем или иным способом обрабатывать ошибочные ситуации)
И есть "как" (на примере с исключениями, "как" — это обрабатывать ошибочные ситуации с помощью исключений, или обрабатывать ошибочные ситуации с помощью кодов возврата)
Так вот, мультиметоды — это "что", а не "как".
Т.е. если провести аналогию с исключениями, то твоё предложение звучит как "куда можно внедрить обработку ошибочных ситуаций?". Очевидно, что если внедрять обработку ошибочных ситуаций в программу, которой совершенно не надо обрабатывать ошибочные ситуации, т.е. в которой нет понятия "ошибочная ситуация", то код действительно от такого внедрения не станет ни проще, ни понятнее.
Я хочу сказать, что мультиметоды нужно внедрять только туда, где есть мультиметоды как таковые. Точнее надо внедрять реализацию мультиметодов.
Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.