точнее, страницу http://www.blogger.com/comment-iframe.g которая попадает в IFRAME?
подозреваю, что никак
пятница, 30 сентября 2011 г.
четверг, 29 сентября 2011 г.
СТОИТ ЛИ ПЕРЕХОДИТЬ НА ДРУГОЙ ЯЗЫК
для практического использования я бы выбирал языки по следующему критерию: является ли новый язык достаточно существенным шагом вперед, чтобы оправдать затраты на обучение по сравнению с прошлым языком
и что самое главное -- нет ли в нем шагов назад? это приведет к крайне неприятной -- а скорее даже недопустимой -- ситуации, когда привычное по старому языку средство не сработает (в то время, как я рассчитывал на него!)
"шаг вперед" обычно понимается в контексте удобства решения конкретной задачи; но для тех, у кого круг решаемых задач достаточно широк (а не ограничен, например, клепанием на конвеере гуев с минимальной логикой), гораздо большую значимость приобретает "неопределенный" контекст; средства работы в этом контексте, скорее всего, в язык программирования не включены -- поэтому интерес представляет расширяемость языка
расширяемость языка нужна так же для тех случаев, когда я написал некоторый код, и хочу, чтобы этот код использовался в максимальной общности (т.е. мне не нужно было переписывать этот код под конкретный частный случай только из-за того, что компилятор языка ограничен в своем понимании); при этом, вполне возможно, мне придется расширить язык, что объяснить компилятору, как автоматически сгенерировать код под конкретный частный случай
пример: хаскель в смысле расширяемости не является существенным шагом вперед по сравнению с с++, т.к.:
1. если на с++ (скорее всего) не составит проблем написать шаблон для map, то в хаскеле:
This puts us in a situation where we really need two copies of every higher-order function, one pure and one monadic. This is even more of a problem when a library (like Data.Map) exports pure versions of some functions but not monadic ones. (http://disciple.ouroborus.net/wiki/Language/Overview/EffectSystem)
2. вместо указания целочисленных аргументов в параметрах шаблона (например, Z< 17 > в с++ может реализовывать кольцо вычетов по модулю 17) в хаскеле возникает необходимость использовать фантомных типов, и, насколько мне известно, написать такой код как
и что самое главное -- нет ли в нем шагов назад? это приведет к крайне неприятной -- а скорее даже недопустимой -- ситуации, когда привычное по старому языку средство не сработает (в то время, как я рассчитывал на него!)
"шаг вперед" обычно понимается в контексте удобства решения конкретной задачи; но для тех, у кого круг решаемых задач достаточно широк (а не ограничен, например, клепанием на конвеере гуев с минимальной логикой), гораздо большую значимость приобретает "неопределенный" контекст; средства работы в этом контексте, скорее всего, в язык программирования не включены -- поэтому интерес представляет расширяемость языка
расширяемость языка нужна так же для тех случаев, когда я написал некоторый код, и хочу, чтобы этот код использовался в максимальной общности (т.е. мне не нужно было переписывать этот код под конкретный частный случай только из-за того, что компилятор языка ограничен в своем понимании); при этом, вполне возможно, мне придется расширить язык, что объяснить компилятору, как автоматически сгенерировать код под конкретный частный случай
пример: хаскель в смысле расширяемости не является существенным шагом вперед по сравнению с с++, т.к.:
1. если на с++ (скорее всего) не составит проблем написать шаблон для map, то в хаскеле:
This puts us in a situation where we really need two copies of every higher-order function, one pure and one monadic. This is even more of a problem when a library (like Data.Map) exports pure versions of some functions but not monadic ones. (http://disciple.ouroborus.net/wiki/Language/Overview/EffectSystem)
2. вместо указания целочисленных аргументов в параметрах шаблона (например, Z< 17 > в с++ может реализовывать кольцо вычетов по модулю 17) в хаскеле возникает необходимость использовать фантомных типов, и, насколько мне известно, написать такой код как
const int n=17; ... Z< n > x;даже с фантомными типами невозможно -- число 17 придется продублировать в форме фантомного типа
Подписаться на:
Комментарии (Atom)