На самом деле да, несмотря на неудачный пример(правильней сравнить, например, разбор списка). Ибо в первом варианте вы просто описывает поток выполнения с операторами перехода. Неймон в полный рост. А во втором случает вы по сути задаете набор «предикат — значение функции». По сути описываете какая ваша функция.
Ну так про идею алгоритма я ничего и не говорил. Речь идет об отсутствии управляющих конструкций типа if в шаблоном коде статье, т.е. об элементах декларативности. Впрочем, не сомневаюсь, что и пример на Scheme можно переписать соответствующим образом.
Скобочки и префиксная запись напрягают, когда на Scheme и других диалектах Lisp не пишешь, а только теоретизируешь о них.
Не сомневаюсь. Более того, думаю, что если бы в школе меня учили писать не z=2*x + 3*y, а что-то типа (setq z (+ (* 2 x) (* 3 y))), то Scheme была бы мне близка и понятна. Что характерно, на С++ я тоже особо не пишу в последние годы, что не мешает мне спокойно читать его код.
Да и назвать шаблонную магию объёмом в несколько раз больше, чем соответствующий код на Scheme, красивой…
Ну во-первых красота измеряется не объемом. Во-вторых само понятие красоты очень субъективно, поэтому постом выше я написал «лично мне». А в-третьих, на мой взгляд, тут сравнивать не совсем корректно. Код на Scheme в статье описан в императивном стиле, а на шаблонах — в декларативном(что-то близкое к pattern matching из функциональных языков).
то же время, остальные члены Интернет-сообщества, угнетенные злобными тиранами Сети, будут с завистью смореть на свободное сообщество Анонимусов и потихоньку переходить в социальную сеть Anonplus.
Думаю, для того, чтобы представить во что превратиться такая социальная сеть, на которую «будут с завистью смореть», достаточно взглянуть на современный вариант двача.
А Scheme в приведенных примерах тоже все считает на этапе компляции? Я честно не в курсе. Ну и лично мне красивым и понятным показался как раз вариант на С++. А в Scheme больше напрягают не скобочки, а обратная польская запись.
На мой взгляд, проблема копипаста в рефератах это лишь следствие. Источник лежит в самой системе обучения, во всяком случае для России. Изучать предметы должны те, кому они действительно интересны — ситуация, когда человек ходить в универ, чтобы откосить от армии или вынужден случать курс экономики предприятия только потому, что минобразования решил, что для звания ВУЗа его надо обязательно включить в программу, является по большому счету уродской. Решить эту задачу можно строгим начальным отбором учащихся, наличием у студента самостоятельно выбирать интересующие его предметы для изучения и введением строго контроля по мере обучения. Так же хорошим стимулом может быть перевод бесплатного обучения на систему грантов — тебе дают деньги, но ты в ответ делаешь некое исследование по заданной теме во время всего времени обучения. Соответственно и рефераты с лабораторными можно давать в рамках темы гранта. Тогда поток копипаста сразу уменьшится, хотя бы из-за риска потерять грант.
А там у них вообще все плохо с компилятором стало. Вот, например, бага с энумератором, которую я нашел. Или вот бага с try...catch, тоже BadImageFormatException.
Безусловно. Но в данном случае гарантируется целостность данных — если произойдет некорректный сет вы об этом сразу узнаете.
А это как раз типическая ошибка подхода: «у нас есть новая возможность, как ее использовать». В то время как правильнее исходить из «у нас есть такая задача, как ее решить».
Как известно одна и даже задача, сформулированная в общих терминах имеет множество решений. Выбор нужного делается на основе тех или иных критериев оптимальности. Я уже говорил ранее, динамическая типизация имеет свои плюсы и соответственно предпочтительна для решения определенных классов задач. Вы же почему-то отбрасываете ее в принципе, исходя из тезиса «не компилируется — значит плохо». Вас не смущается, что множество веб-решений, комплексная сложность которых вполне сравнима(а то и превосходит) со сложностью десктоп приложений, делаются на языках с динамической типизацией(причем даже менее строгой, чем та, которой привел я в своей статье)?
habrahabr.ru/search/?q=automapper
Вы сами ходили по этой ссылке? Если да, то в какой из этих статей решается задача «автоматического добавления новых свойств для объектов, возвращаемых методами и функциям»? Мне лично кажется, что не в какой, ибо автомаппер в принципе не предназначен для этого. Кстати говоря, что будет, если в одном из классов, который мы маппим, я поменяю имя свойства? А ничего не будет, все прекрасно скомпилируется. Ошибка будет уже на рантайме.
Мир не ограничивается WPF, вот в чем дело. MVVM используется не только там, и задача создания моделей возникает не только там. В вашей статье WPF возникает только в конце, а до этого вы говорите об абстрактном MVVM.
Я вам просто пример привел. Не нравится WPF — возьмите Silverlight. А в связке (html+css+js), на которой строятся современные веб-интерфейсы, статической типизацией и не пахло. И ничего, никто не умирает.
Я понимаю, если бы вы мне указали на то, что на текущий момент dynamic плохо поддерживается статическими анализаторами кода. Это да, недостаток. А статика сейчас все больше сдает позиции.
Честно говоря, я в своем сообщении имел ввиду в первую очень рынок европы и США, как наиболее прибыльный. Еще интересна Япония и Южная Корея. Очевидно, что например в африке, афганисте и прочих странах 3-его мира будут лидировать самые дешевые модели телефонов. А в китае, подозреваю, у множества жителей мобильного вообще нет. В России(если мы будем смотреть в регионы, а не в крупные города) ситуация примерно такая же. Собственно вот вам статистика Что касается цен на продукцию эппл в России, то это проблема нашего рынка, государства и общего подхода к торговле(из серии «пусть лучше сгниет на складе, но цену я не сброшу»).
И в вдогонку — когда вы начинаете использовать дататемплейты, стили, триггеры и байдинги в WPF, то очень часто проверка ошибок на этапе компиляции превращается в пыль. Вы никогда не сталкивались с ситуацией, когда байдинг на какой-нибудь прекрасно скомпилированной странице/контроле не работает, т.к. не правильно заданно имя свойства или в датаконтексте по воли злого рока оказался объект не того типа, которого вы ожидали? Является наличие таких особенностей при построении UI через хaml и WPF поводом отказаться от их использования?
И знаете, в чем крупный и отвратительный недостаток этого подхода? В том, что ваш код перестал быть типизированным. Любые ошибки и опечатки вы отловите уже после компиляции.
Ну во-первых да, знаю, что он перестанет быть типизированным(думаю многие об этом начали догадываться еще прочитав слово dynamic в заголовке). Во-вторых то, что это недостаток, еще очень спорный вопрос. Динамическая типизация имеет как свои плюсы, так и минусы. Посмотрите на тот же питон — на нем прекрасно пишутся приложения, хотя типизация самая что не наесть динамическая. Ну или обжект-си в плане посылки сообщений. Да, ошибки отлавливаются уже после компиляции и по-этому на динамических языках стараются писать через TDD. Впрочем я лично считаю, что и на статике это будет не лишним. Что же касается данного примера, то обратите внимает, что речь идет о довольно простых объект, которые не должны содержать сложную логику, которая сломается. К тому же тем не менее типизацию в каком виде я сохраняю — например если свойство было задано как int, записать в него строку уже не получится.
При этом вы зачем-то зациклились на прокси
Была поставлена задача и предложено решение на основе прокси. Сама задача была взята как база для рассмотрения вопроса о том, как можно использовать новый тип, появившийся в спецификации C# 4.0
эти задачи прекрасно решаются с помощью обычных объектов и маппинга. А отсюда вырастает целый класс решений по этому поводу, начиная с AutoMapper.
Прекрасно если это так, с удовольствием прочитаю вашу статью об этом. Не забудьте об по ставленом в задаче условии автоматического добавления новых свойств для объектов, возвращаемых методами и функциям.
P.S. Ваш комментарий, на мой взгляд, чрезмерно эмоциональный и несет в себе конфликт-агенты. Мне кажется не стоит продолжать дискуссию в таком тоне, вы не находите?
Можно шагнуть чуть дальше и писать что-то типа
declarative(1) = "one"
declarative(2) = "two"
declarative(_) = "many"
Вы отвечаете — «Тот факт, что нет явных if не делает код декларативным.»
Вам не кажется, что наши утверждения не вступают в противоречие и таким образом нет предмета спора?
Не сомневаюсь. Более того, думаю, что если бы в школе меня учили писать не z=2*x + 3*y, а что-то типа (setq z (+ (* 2 x) (* 3 y))), то Scheme была бы мне близка и понятна. Что характерно, на С++ я тоже особо не пишу в последние годы, что не мешает мне спокойно читать его код.
Думаю, для того, чтобы представить во что превратиться такая социальная сеть, на которую «будут с завистью смореть», достаточно взглянуть на современный вариант двача.
Безусловно. Но в данном случае гарантируется целостность данных — если произойдет некорректный сет вы об этом сразу узнаете.
Как известно одна и даже задача, сформулированная в общих терминах имеет множество решений. Выбор нужного делается на основе тех или иных критериев оптимальности. Я уже говорил ранее, динамическая типизация имеет свои плюсы и соответственно предпочтительна для решения определенных классов задач. Вы же почему-то отбрасываете ее в принципе, исходя из тезиса «не компилируется — значит плохо». Вас не смущается, что множество веб-решений, комплексная сложность которых вполне сравнима(а то и превосходит) со сложностью десктоп приложений, делаются на языках с динамической типизацией(причем даже менее строгой, чем та, которой привел я в своей статье)?
Вы сами ходили по этой ссылке? Если да, то в какой из этих статей решается задача «автоматического добавления новых свойств для объектов, возвращаемых методами и функциям»? Мне лично кажется, что не в какой, ибо автомаппер в принципе не предназначен для этого. Кстати говоря, что будет, если в одном из классов, который мы маппим, я поменяю имя свойства? А ничего не будет, все прекрасно скомпилируется. Ошибка будет уже на рантайме.
Ну во-первых да, знаю, что он перестанет быть типизированным(думаю многие об этом начали догадываться еще прочитав слово dynamic в заголовке). Во-вторых то, что это недостаток, еще очень спорный вопрос. Динамическая типизация имеет как свои плюсы, так и минусы. Посмотрите на тот же питон — на нем прекрасно пишутся приложения, хотя типизация самая что не наесть динамическая. Ну или обжект-си в плане посылки сообщений. Да, ошибки отлавливаются уже после компиляции и по-этому на динамических языках стараются писать через TDD. Впрочем я лично считаю, что и на статике это будет не лишним. Что же касается данного примера, то обратите внимает, что речь идет о довольно простых объект, которые не должны содержать сложную логику, которая сломается. К тому же тем не менее типизацию в каком виде я сохраняю — например если свойство было задано как int, записать в него строку уже не получится.
Была поставлена задача и предложено решение на основе прокси. Сама задача была взята как база для рассмотрения вопроса о том, как можно использовать новый тип, появившийся в спецификации C# 4.0
Прекрасно если это так, с удовольствием прочитаю вашу статью об этом. Не забудьте об по ставленом в задаче условии автоматического добавления новых свойств для объектов, возвращаемых методами и функциям.
P.S. Ваш комментарий, на мой взгляд, чрезмерно эмоциональный и несет в себе конфликт-агенты. Мне кажется не стоит продолжать дискуссию в таком тоне, вы не находите?