Здравствуйте, Ikemefula, Вы писали:
I>На практике надо посадить на немерле не только всю комманду, но и людей, которые потенциально могут стать частью этой комманды.
I>При этом надо будет показать, что производительность труда на голову выше чем у конкурентов.
Nemerle создает стандартные .Net сборки. Так что достаточно посадить одного инструментальщика.
R>>$"Output: $a"
R>>string.Format("Output: {0}", a)
R>>
R>>но где здесь 5 спецсимволов и где здесь клиника?
I>Где там 5 спецсимволов, неясно.
I>Но вот код такой просто клиника.
Да ну А обоснования будут?
I>Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.
Студенту однофигственно придется объяснять что первое что второе. Причем, не факт, что первый вариант сложнее для понимания. PHP (да не в суе будет упомянут) тому яркий пример, там сплайс-строки умудряются применять и люди, знакомые с программированием лишь поверхностно.
Так что вопрос прозрачности больше тут связан как мне кажется с инертностью мышления и силой привычки
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.
VE>Все рождены в равенстве и с равными возможностями!
Я же вроде уточнил, что говорю о данном случае?
Я правильно понимаю, что это сейчас было утверждение "метапрограммистами не становятся, ими рождаются"? Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого. Научить же передавать через рисунок свои чувства (а тем более, чувства других людей), практически нереально, этому необходимо учится самому, имея некоторый врожденный фундамент и желание/стремление. Восприимчивость к такого рода самобучению и называют талантом. Так вот, освоить МП — это как научиться использовать новую технику в рисунке. Никаких талантов для этого не требуется, чистый формализм и механика. А вот то, как художник/программер эту технику будет применять в своих работах — это уже формализм совсем не всегда. Но и тут никаких новых талантов, кроме тех, что у хорошего художника/программера уже есть, и не нужно.
Забавно, пока писал про техники, вспомнил, как мы осваивали в школе на уроках живописи, одну из оных. Ее суть сводилась к следующему: в качестве холста для работы выступал кусок оргстекла, нужного размера. Рисунок наносился на стекло кистью, с использованием крайне размоченной на палитре акварели (точнее даже, воды с небольшим добавлением акварели), очень крупными и весьма условными мазками. После этого, холст (мы использовали ватман) обильно пропитывался водой и нашлепывался на это стекло. Сверху ложился еще один кусок стекла, и весь этот бутерброд придавливался чем-нибудь тяжелым (чтобы холст не покоробило от влаги). Когда краска высыхала, холст отдирался от обоих стекол и, сначала просто влажной кисточкой, а потом пером с тушью уточнялись контуры рисунка, смазанные из-за водянистости техники и смещений холста при нашлепывании.
Работы, выполненные этой техникой, получались безумно красивые воздушные, легкие цвета, плавные переходы оттенков, интересные артефакты и фактуры из-за неравномерной концентрации красок, которые потом можно было обыграть дополнительной тушевкой и контуром. И это при том, что общая композиция рисунка оставалась практически в полном соответствии с задуманной.
Эта техника отличалась от всех остальных, ранее нами изученных, в т.ч. и следующим:
1. Позволяла крайне быстро получить работы необычайной красоты и выразительности
2. Основной базис для рисунка со всеми его богатыми фактурами и переходами выполнялся не художником, а другим, более огрубленным рисунком, нанесенным заранее на стекло.
3. Овладение пером и навыками уточнения контуров хоть и потребовало некоторое время, но результат того стоил однозначно
4. Концентрация творческой составляющей, преимущественно на последней стадии позволила целиком и полностью посвятить себя на ней передаче своих эмоций, а не размазывать этот процесс по всем этапам, как в других техниках.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Я правильно понимаю, что это сейчас было утверждение "метапрограммистами не становятся, ими рождаются"?
Разумеется. Ну т.е. становление тоже имеет место, но далеко не 100%, и даже скорее всего не 50. Захотеть тоже надо уметь. Гены сильная штука. В принципе можно и кролика научить курить (вопрос времени и денег), но вот есть люди, какие есть. Есть даже неспособные понять указатели.
KV>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.
Если под рисованием понимать "возить кисточкой по бумаге", то да. И я даже не про передачу чувств, я просто про качественные рисунки.
KV>Так вот, освоить МП — это как научиться использовать новую технику в рисунке. Никаких талантов для этого не требуется, чистый формализм и механика.
И время и деньги. И способности. Вон тут монады некоторые понять не в силах. И таких наверняка большинство. А ключевое слово какое-нибудь присобачить, делающее то же самое — это поймёт почти любой. Вроде нет разницы, а вроде вот она.
В любом случае это не по теме, у AVK есть вроде как более конкретные претензии. Но большинством это вопринимается "МП в Немерле ненужное говно, им никто не в состоянии овладеть и оно сложное". И они считают своим долгом рассказать, как можно человека научить понять простую макру, хотя к теме это отношения не имеет. Некоторые идут ещё дальше и слышат "Немерле говно". Потому и ответы в стиле "можно писать как на C#". Казалось бы, причём тут МП?
Здравствуйте, mihailik, Вы писали:
R>>но где здесь 5 спецсимволов и где здесь клиника?
M>1) $ M>2) " M>3) : M>4) $ M>5) "
M>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.
Скажите мне, что это стеб А то невольно вспоминается разговор про синтаксический оверхед господина Губанова
Здравствуйте, IT, Вы писали:
IT>$"Output: $a" IT>string.Format("Output: {0}", a)
IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
Плюс проверка типов параметров во время компиляции.
Здравствуйте, Ikemefula, Вы писали:
I>Откуда взялись твои оценки сложности ? Здесь то и зарыта собака.
I>Разумеется, если разработчик в состоянии осилить такую глубину и большую, то ему будет легче. Речь то не об этом.
I>Судя потому, что люди плохо понимают виртуальные методы, интефейсы, индексеры, итераторы и эвенты, любое новшество это уже чрезмерное усложнение.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, IT, Вы писали:
IT>>$"Output: $a" IT>>string.Format("Output: {0}", a)
IT>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
I>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.
А если я тебе скажу что во втором варианте могут быть рантайм ошибки, а первый их отловит на этапе компиляции?
Здравствуйте, alvas, Вы писали:
A>А если я тебе скажу что во втором варианте могут быть рантайм ошибки, а первый их отловит на этапе компиляции?
Расскажите мне, как он их отловит. Вдруг и правда?
А то у меня подозрение, что он может отловить только одну рантайм ошибку, которая может быть во втором случае.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, alvas, Вы писали:
A>>А если я тебе скажу что во втором варианте могут быть рантайм ошибки, а первый их отловит на этапе компиляции? VE>Расскажите мне, как он их отловит. Вдруг и правда? VE>А то у меня подозрение, что он может отловить только одну рантайм ошибку, которая может быть во втором случае.
VE>>И?
A>Нужно переходить на следующий уровень мышления.
Кому нужно? Кому нужно, чтобы большое кол-во программистов перешло на следующий уровень мышления?
Здравствуйте, Sinclair, Вы писали:
S>Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.
S>И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.
Настоящая проблема precompile генерации не в том, что трудно писать генераторы, а в том, что precompile генераторами трудно, если вообще возможно гибко управлять. Т.е. вместо того, чтобы подойти к двери и прочитать табличку занято, мы начинаем ходить вокруг да около, заглядывать в замочную скважину и ждать пока оттуда кто-то выйдет или туда войдёт. Т.е. более менее сложная генерация должна делаеться на основе невнятных эвристик.
Для твоего примера в той же compile или run-time генерации можно для параметризации view задействовать, например, атрибут и добавить небольшую ветку в генератор, анализирующий этот атрибут в подходящем месте. Пользователь сам указывает, что он хочет, проблема решена, затрат минимум и главное никаких эвристик по вторичным половым признакам, что и делает эти генераторы сложными.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Откровенно говоря — это все не конкретные какие-то рассуждения. Слишком много нюансов. Правильно спроектированный генератор не должен приодить к проблемам при изменении модели или свойств генерируемого кода. Тем более, что конечная модель у такого генератора — это скорее всего текст (или на худой конец какое-то АСТ вроде System.Linq.Expressions.Expression).
VD>В любом случае менять сгенерированный текст — это самое хреновое решение.
Ну, на самом деле есть два способа работы с precompile генераторами:
1. Сгенерировал и забыл про генератор.
2. Сгенерировал и забыл про изменение кода.
Первый вариант тоже имеет право на жизнь и часто используется. У меня в конторе народ генерирует генератором Linq2SQL набор классов по БД, зачем вычищает оттуда весь мусор и уже далее поддерживает этот код вручную. В принципе, ничего плохого в этом нет. Небольшая автоматизации на начальном этапе.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, Ikemefula, Вы писали:
I>>Откуда взялись твои оценки сложности ? Здесь то и зарыта собака.
I>>Разумеется, если разработчик в состоянии осилить такую глубину и большую, то ему будет легче. Речь то не об этом.
I>>Судя потому, что люди плохо понимают виртуальные методы, интефейсы, индексеры, итераторы и эвенты, любое новшество это уже чрезмерное усложнение.
A>Это проблема думать на Блабе
А обоснования будут?
Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого. Научить же передавать через рисунок свои чувства (а тем более, чувства других людей), практически нереально, этому необходимо учится самому, имея некоторый врожденный фундамент и желание/стремление. Восприимчивость к такого рода самобучению и называют талантом. Так вот, освоить МП — это как научиться использовать новую технику в рисунке. Никаких талантов для этого не требуется, чистый формализм и механика. А вот то, как художник/программер эту технику будет применять в своих работах — это уже формализм совсем не всегда. Но и тут никаких новых талантов, кроме тех, что у хорошего художника/программера уже есть, и не нужно.
воздушные, легкие цвета, плавные переходы оттенков, интересные артефакты и фактуры из-за неравномерной концентрации красок, которые потом можно было обыграть дополнительной тушевкой и контуром. И это при том, что общая композиция рисунка оставалась практически в полном соответствии с задуманной.
А то невольно вспоминается разговор про синтаксический оверхед господина Губанова 
Если нам не помогут, то мы тоже никого не пощадим.
