Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 19:10
Оценка: 83 (9) +1
Дисклеймер:
1) Все сказанное ниже это мое личное мнение в моих конкретных условиях. На истину я не претендую.
2) Все сказанное относится только и исключительно к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков.
3) Попытки обсудить меня лично, мою квалификацию, опыт или мое психическое и психологическое состояние, а так же прочие медицинские и моральные вопросы, аутоматично приводят к тому, что попытавшиеся товарищи идут в лес.

Итак, сабж.
1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.
При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.
Итого — внесение изменений в компилятор для улучшения языка лично для меня с точки зрения промышленного программирования малополезно (при этом побаловаться для проектов, рассчитаных на одну-две хари фо фан я как бы и не против).
2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.
Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.
3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.
4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.
5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.

P.S. Еще раз, если кто то в корне со мной не согласен, прежде чем бросаться писать возмущенный ответ и разгромить меня в пух и прах, обратите внимание на наличие и содержание дисклеймера.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 01:57
Оценка: 145 (6) +2
Здравствуйте, AndrewVK, Вы писали:

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


Инженер, который не знает инструмента, с которым он работает, не может эффективно выполнять свои функции в принципе. С программистами, которые не хотят изучать новые технологии или даже противятся этому, рано или поздно начинаются проблемы из серии "тупой дизайн, кривой код". Причём чем выше статус такого человека в команде, тем разрушительнее последствия. Я не знаю как эти вещи связаны между собой, может это чистое совпадение, но в моей практике это совпадение сто процентное, что позволяет мне сделать вывод, что оно не случайно. Для меня это даже стало очень чётким индикатором, человек не интересуется, не может освоить новое — ничего хорошего от него не жди. Под таких людей нужно не подстраиваться, а пытаться их учить, а если не получается, то постараться от них избавится.

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


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

Главная проблема при изучении нового не в запоминании названия функций и конструкций языка. Главная проблема в освоении новых концепций. Тот же yield return не сложно запомнить, гораздо сложнее разобраться с ленивостью. А разобравшись будет уже не важно как это реализуется, функцией, макросом или языковой конструкцией. Ведь ни функции, ни макросы, ни ключевые слова сами по себе не вводят новых концепций, они их реализуют и являются всего лишь следствием, формой.

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

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


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

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


Насколько мне известно, аббревиатура DSL в DSL Tools появилась по недоразумению. С DSL эти Tools имеет мало обощего.

AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.


Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст. Дело в том, что текст обычно генерируется последовательно, от начала до конца. Код в Немерле можно генерировать в произвольном порядке, что даёт определённую гибкость. А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Не знаю зачем ты добавил сюда этот пункт, но МП тут вообще ни при чём. Если у тебя задача не может использовать МП, или ООП, или ФП, то странно в этом обвинять МП, ООП, или ФП.

В общем, как-то всё не очень убедительно. Фактически я увидел две претенции:

1. Сложноть использования макросов.
2. Сложность написания макросов.

По первому пункту я уже всё сказал. Это не сложнее, чем использование классов, методов и атрибутов. Сложность не в макросах, сложность в концепциях, которые они реализуют. Но это в равной степени относится и к тем же классам, методам и атрибутам.

По второму пункту можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать. МП тоже скил, который тоже нужно тренировать. Во многом эти скилы пересекаются, так что не вижу в этом большой проблемы.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 12:50
Оценка: 75 (4) +4
Здравствуйте, IT, Вы писали:

IT>Инженер, который не знает инструмента, с которым он работает, не может эффективно выполнять свои функции в принципе.


Все это здорово и правильно. Но вот нету тут никакой бинарности. Спектр знания инструмента непрерывен. И человека, который не очень хорошо представляет себе концепцию итераторов, вполне можно использовать с положительным выхлопом.
Я тут уже мысль расшифровывал — вопрос не в принципиальной возможности или невозможности, вопрос даже не совсем технический, вопрос в банальном бабле. Ну то есть — в данном конкретном случае, что будет больше, выигрышь от улучшения языка или проигрышь в поиске программистов. Увы и ах, у меня нет никакой возможности формировать команду из элиты, приходится работать с тем, что есть. И это, конечно, не бестолковые индусы, это просто люди, у которых пока не наработан большой опыт. Они, конечно, со временем его приобретут, и буду не хуже тебя или меня. Но продукт то нужен здесь и сейчас. А благие намерения, увы, ничего не стоят.
Собственно, я не помню, высказывал я эту мысль или нет, но концепция языка программирования это не только и не столько технический вопрос. Язык только одним концом нацелен на техническую железку. Другим концом он нацелен на человека. И очевидно, что, таким образом, важнейшим фактором является ориентированность на человеческую психологию. Причем, учитывая сложность системы и все возрастающие технические возможности, эта ориентированность все больше и больше увеличивается.
Именно в этой особенности мне видится популярность таких языков, как php. Ведь с технической точки зрения — убожество, каких поискать.

IT>В промышленном программировании любой более менее серьёзный проект включает в себя фреймворк или библиотеку с общими компонентами.


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

IT>Главная проблема при изучении нового не в запоминании названия функций и конструкций языка. Главная проблема в освоении новых концепций.


Ну да. Я здесь же вчера писал ровно то же самое.

IT> А разобравшись будет уже не важно как это реализуется, функцией, макросом или языковой конструкцией.


Я думаю, все таки важно. Но не суть. Опять же, моя мысль не в том, что важна реализация. А в том, что в отсутствие макросов набор таких концепций зафиксирован, у меня есть немалые шансы, что, наняв разработчика со стороны, я обнаружу у него понимание таких концепций. А вот с нестандартными концепциями, реализованными макросами, у меня таких шансов уже заметно меньше.

IT> Ведь ни функции, ни макросы, ни ключевые слова сами по себе не вводят новых концепций, они их реализуют и являются всего лишь следствием, формой.


Я же уже вроде писал — ничего не имею против, если макросы используются для разработки языка в рамках, заданных well known стандартом. Ну так, чтобы я мог требовать знание этих концепций при приеме на работу, и иметь при этом шансы кого то нанять.

IT>В общем, сложность использования макросов надумана


Видишь ли, я про сложность использования макросов ничего не писал. Я про сложности, порождаемые их использованием. А использовать да, использовать их просто, не могу не согласиться.

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


Я тоже так думал. А на практике оказалось, что этот DSL приходится поддерживать постоянно. Если DSL этот — ключевое момент системы, это еще ничего. А вот если вспомогательный — сложно все таки мыслить концепциями генераторов, сложнее, чем просто писать целевой код.

AVK>>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


IT>Насколько мне известно, аббревиатура DSL в DSL Tools появилась по недоразумению.


Это спор о терминах. Лично я считаю, что все там по разумению. Вполне нормальное средство разработки графических domain specific языков.

AVK>>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


IT>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код.


Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?

IT>Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст.


Опять же, ты неверно понял. Я нигде не писал, что генерировать код на Немерле сложнее, нежели генерировать текст. Я говорил о другом — нередко проще вообще ничего не генерировать. Это все я написал к тому, что была у меня задача создания довольно сложной модели и ее реализации в условиях цейтнота. Тогда я справился при помощи кодогенерации, и очень быстро получил результат. Но теперь, по проществии нескольких лет, приходится признать, что на поддержку генератора я затратил больше усилий, чем если бы я ничего не генерировал с самого начала и просто рефакторил бы готовый код.

IT>Не знаю зачем ты добавил сюда этот пункт, но МП тут вообще ни при чём.


Влад в соседней ветке утверждал, что любая кодогенерация это МП. По мне так называй как хочешь, непринципиально.

IT>1. Сложноть использования макросов.


Нет такой притензии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 21:26
Оценка: -3 :))) :)
R>но где здесь 5 спецсимволов и где здесь клиника?

1) $
2) "
3) :
4) $
5) "

Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.
Re[3]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 13:14
Оценка: 1 (1) +3 -2
Здравствуйте, IB, Вы писали:

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


VD>>Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.

IB>Влад, ты задрал. На долго тебя действительно не хватило.

Кого я задрал? Он что девочка обижаться на примитивные вопросы?
Тупо отбрасывает неугодные ему факты и строит "логику" на тех, что ему нужны.
Это чистой воды обман или незнание предмета обсуждения.

IB>Я далеко не во всем согласен с АВК, да и задачи у меня другие, но наблюдать со стороны твою демагогию крайне не приятно.


С начало не плох было бы продемонстрировать демагогию в моих словах.
Демагогия, а точнее софистика как раз сплошь и рядом в словах АВК.

VD>>Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.

IB>Не снимает. Проблема не в том, что можно так не делать, проблема в том, что так делать в принципе можно, об этом говорилось уже ни раз.

Это не аргумент. Синтаксические расширения — это не грипп. Их нельзя подхватить случайно. Запрети в своей конторе их использовать или дай разрешение на их введение только определенным лицам (т.е. себе любимому) и проблема исчезнет как класс.

К тому же вам сто раз говрили люди которые все это используют на практике — нет проблем от синтаксических макросов. Вообще нет. Над тем же Немерлом работали в разное время десятки человек и в вакханалию ничего не превратилось.
С точки зрения использования нет особой разницы вводится ли новый макрос, или новый класс. Последствия совершенно одинаковые.

Вот где действительно есть проблемы, так это в качестве написанных макросов. Оно должно быть на высоте, так как макра — это фактически плагин к компилятору и IDE, а значит она может повлиять на их работу. Но это опять же имеет прямую корреляцию с библиотеками. Не давайте кому попало писать критический код.

VD>>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.

IB>Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

Андрей просто неверно трактует термины встроенный DSL и мета-программирование. Об этом я и говорил.

VD>>Из определения ясно видно, что это не усеченные или расширенные языки программирования общего назначения, а совершенно другие языки описывающие предметную область и оперирующие терминами из этой области.

IB>То есть, ты утверждаешь, что переходя в термины предметной области ты не сужаешь набор возможностей?

Да, и это нужно четко понимать если уж ты взял на вооружение ДСЛ-подход.
Ты не сужаешь и не расширяшь базовый язык. Ты вводишь в язык некий подъязык с совершенно другой семантикой, а возможно и синтаксисом. Это может быть сделано разными средствами (не только через МП), но после того как это сделано, рассматривать ДСЛ как сужение или расширение основного языка ошибочно и пагубно.

IB>И не составит никаких проблем описать бухгалтерию точки общественного питания в терминах системы управления АЭС?


Ты сейчас намеренно сказал глупость. Зачем?
Конечно описывать бухгалтерию в терминах АСУТП АЭС глупо. Скажу даже больше невозможно.
Но встроить в один язык два подъязыка-ДСЛ-я один из которых позволит описать предметную область бухгалтерии, а другой АСУТП АЭС можно. Вряд ли это потребуется в одном проекте, но это ведь не проблема?

VD>>Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.

IB>С набором ограниченных возможностей.

Не. С совершенно иной семантикой! Ты просто не пишешь на базовом языке, а пишешь на ДСЛ-е. Давай перейдем от абстракций к конкретике. Вот у нас есть конкретный ДСЛ — регулярные выражения. Как они сужают базовый язык? Да они к нему просто не имеют никакого отношения! Они романтически совсем другие. Разбор регулярных выражений можно реализовать на языке общего назначения (ЯОН), но нельзя выразить с его помощью.
Улавливаешь разницу? Ну, так вот используя скажем Шарп ты можешь реализовать класс который будет принимать ДСЛ регулярных выражений в качестве строки и производить сопоставление. И то, и другое будет производиться в рантайме. Скажем реализация регекспов в дотнете может скомпилировать их на лету чтобы ускорить их работу. Вот эта компиляци, а точнее генерация для нее кода — это и есть МП. Немерле же позволят:
1. Производить разбор и анализ ДСЛ-я в процессе компиляции.
2. Легко сгенерировать эффектинвый код, опять же во время компиляции.

Неужели это плохо?

VD>>Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).

IB>Во-первых, никто не обещал рассказывать про проблемы МП в немерле, обещали рассказать чем не устраивает немерле именно AVK, и именно это и рассказали.

Вообще-то обещал. Но в другой теме.

IB>А во-вторых, рассказали на чем именно основаны "предубеждения".


Да не очень то. А вот, то что это предубеждения ясно любому кто знаком с Немерле не по наслышке. Заметь не нашлось никого, кто хоть немного знал бы этот язык и при этом согласился бы с АВК.

VD>>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.

IB>А ты не хами и жалеть не придется.

А в чем хамство то? Для него хамство — это когда я называю вещи своими именами. Я говорю, что он намерено или нечаянно опускает из рассмотрения вещи с которыми он (по всей видимости) не может конструктивно спорить. Это хамство? тогда, рабята с вами вообще нельзя что-то обсуждать, так как хамством для вас является любое сомнение в вашей правоте. А не то что бы сомневался. Я отчетливо вижу отсутствие этой самой правоты.

VD>>Ведь только в честных спорах рождается истина.

IB>Возможно. Но только честно спорить ты не умеешь.

Да, конечно. Ты меня Вань извини, но слова АВК — это большей частью демагогия не имеющая никакого отношения к техническим аспектам. И все это проистекает из-за того, что человек пытается найти технические обоснования для сугубо субъективных предпочтений.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 30.12.08 05:18
Оценка: +4 :))
Здравствуйте, VladD2, Вы писали:

VD>Дык если бы каждый чих этого требования, то проблему бы давно решили написав набор стандартных функций или введя синтаксис аналогичны сринг-формату. На на практике потребность фоматировать даблы столь редка, что о ней и говорить не приходится. К тому, же всегда можно настроить все через культуру. Это зачастую снимает много проблем.

Это от того, что единственное, что вы пишете — это компилятор. У вас там наверное во всём проекте ни одного дабла, кроме как в тесткейзах, нет.
А в жизни ни даты, ни даблы никто никогда не выводит в "дефолтном" формате. Слишком велик разброс вариантов. Задавать же, к примеру, количество знаков после запятой, через культуру — еще менее удобно, чем подставлять ad-hoc функцию. В культуре есть понятие стандартного вывода денежных значений. Но никакого типа currency нет, а сплайс-строки не предоставляют возможности использовать эту настройку. В String.Format я пишу {0:C} и всё — будет выводиться корректный префикс и количество цифр после точки.

VD>Все эти F2 и FX действительно затрудняют понимание и никакими курсами тут не поможешь. Я вроде уже боец не молодой, но запомнить эту ересь я не могу. А функция затрудняет понимание нее больше чем знаки форматирования. Скажу больше, функция может содержать описание которое будет видно из подсказки (хинта) в IDE. Это решает проблему чтения, в отличии от срок форматирования.


VD>Ладно, вопрос риторический. Я считаю, что решения должны быть интуитивно понятными. Тогда и документацию смотреть не потребуется. А формат в старин-формат сдалан в лучших традициях перла. Никакой логики, одни двухбуквенные согращения. Но за-то народ привыкший к этому дерьму и не видевший ничего более разумного начинает с пеной у рта отстаивать это уродство.


Ну, я, собственно, уговаривать тебя не собираюсь. Я не пользуюсь Nemerle, и задачи продвинуть его в top100 языков программирования у меня нету.
Но то, что вы позиционируете как killer feature штуку, которая сильно отстаёт по возможностям от "родного" аналога, удручает.
Так ты слона не продашь (с).

Понимаешь, идея не в том, чтобы сказать всем "вы косные тупые уроды, бросьте всё и пишите как мы, пусть это будет длиннее по строчкам кода", а в том, чтобы сказать "смотрите, привычные вам вещи умеют больше".

VD>Кстати, одно из соображений почему мы не сделали формат аналогичный стринг-форматному как раз и была полная непонятность этого формата. А ведь еще в 6-ом Васике вроде как были весьма интуитивно понятные средства форматирования.

Не вижу ничего непонятного. По сравнению с синтаксисом RegEx форматные строки — детский лепет. Реально, Влад, это еще один DSL, существующий в рамках .Net. Вот взяли бы его и замутили на Nemerle. Так, чтобы все там пряники типа компайл-тайм проверки, code completion, и так далее.
А то, что вы сейчас позиционируете как killer feature, извини, не намного лучше прямого вызова String.Concat.

VD>Это не правда. Ты просто плохо смотрел. Вот, например.

Да, правда, плохо смотрел.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 04:14
Оценка: 81 (3) +2
Здравствуйте, Ikemefula, Вы писали:

I>По этой причине людям стараются дать технологии, которые не отнимают времени на освоение.


Типа PHP? Ребята, это не серьёзно. Если бизнес модель твоей компании базируется на эксплуатации дешовых кодеров-пэтэушников, которые в состоянии использовать только примитивные технологии, то МП однозначно не для тебя. Не заморачивайся. Купи одну книжку ПХП за три дня на всю контору и этого будет более чем достаточно. Вкладывайте деньги не в обучение, не в качество, а в количество. Возможно такая модель более прибыльна. Хотя, судя по тому как сейчас трещит по швам индусский аутсорсинг, это не совсем так в определённой перспективе.

>>Причём чем выше статус такого человека в команде, тем разрушительнее последствия. Я не знаю как эти вещи связаны между собой, может это чистое совпадение, но в моей практике это совпадение сто процентное, что позволяет мне сделать вывод, что оно не случайно. Для меня это даже стало очень чётким индикатором, человек не интересуется, не может освоить новое — ничего хорошего от него не жди. Под таких людей нужно не подстраиваться, а пытаться их учить, а если не получается, то постараться от них избавится.


I>Да, это хороший подход. Работает исключительно в коммандах из топ-разработчиков.


Это работает всегда. От проблемных людей надо избавляться. Команда из 5-7 человек с проблемным мембером работает гораздо эффективнее без него. Уж поверь мне на слово, как ведущему сабокоеду, съевшему не одну собаку на корпоративной грызне пока я работал в IBM. Убираешь такого человека из команды и работа начинает в буквальном смысле спориться. Исключений не бывает.

I>С плохими технологиями всегда так — чуть что, виноватые не создатели технологии, а тупые разрабы, потому что видители у топов все отлично.


Так всегда не с плохими технологиями, а с плохими топами. Люди могут ошибаться, в том числе и по объективным причинам. Это нужно понимать и признавать. Более того, нет ничего проще, чем разделить ответственность за свои решения со всей командой. Достаточно просто обсудить эти решения с ней и всё. Никто не виноват

I>Это тебе кажется, что не сложнее. А реально — много сложнее. Примерно на порядок.


Чушь. Из какого пальца "порядок" высасывал?

I>У меня был случай, когда я понаписывал макросов а товарищи по проекту отказались их использовать и долбили копи-пастом.


Давай посмотрим на твой макрос и подумаем, что с ним не так. Думаю, что скорее всего проблема в том, что ты его писал не для того, чтобы решить конкретную проблему, а для того, чтобы его написать. Вообще, это очень правильный вопрос "а какую проблему мы решаем?". Если бы ты задал его себе сам или тебе задали бы твои коллеги, то может правильное решение пришло бы гораздо быстрее.

I>Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.


Т.е. геморрой был изначально и скорее всего аккуратно был перенесён в макрос

IT>>Главная проблема при изучении нового не в запоминании названия функций и конструкций языка. Главная проблема в освоении новых концепций. Тот же yield return не сложно запомнить, гораздо сложнее разобраться с ленивостью.


I>На этом срубается примерно 90% разработчиков, а остальные 10% рассматривать как целевую аудиторию для новых технологий как минимум несерьезно.


А ты пробовал им объяснять как это работает? Я пробовал много раз и ты знаешь, люди начинают понимать. Причём обяснял даже не мелом на доске, а пальцем на окне вагона метро. И итераторы, и всю функциональщину. Люди это понимают, но для этого нужно обязательное выполнение двух условий:

1. Желание объясняющего объяснять.
2. Необходимый базовый уровень знаний обучаемого.

В частности, человеку с C++ бэкграундом, знающему что такое указатель на функцию, вся функциональщина объясняется на раз. Как её применять он уже потом сам научится, но что это такое и как это всё работает объяснить не составляет проблем.

С другой стороны, объяснить, например, двухлетнему ребёнку смысл слова "ответственность" практически не реально. Он ещё не оперирует базовыми понятиями, на которых можно строить объяснение. Поэтому, маленьким детям и юным кодерам говорят, что солнце пошло спать, а уже взрослым, что Земля вращается вокруг своей оси.

IT>>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.


I>Сложности нет. Сложность в людях.


Сложность в неверии в людей и в костности мышления.

IT>>А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.


I>Вполне возможно, что инструмент вышел немного не тот, что задумывался, потому за баранизмом надо искать проблемы, чего людям надо то.


Сто процентов не тот. Precompile генерация кода — не тот инструмент по определению.

IT>>По первому пункту я уже всё сказал. Это не сложнее, чем использование классов, методов и атрибутов. Сложность не в макросах, сложность в концепциях, которые они реализуют. Но это в равной степени относится и к тем же классам, методам и атрибутам.


I>Это справедливо только для разработчиков топ-уровня.


Это не справедливо только для джуниоров — 0-3 года опыта. И то не для всех.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 12:50
Оценка: +1 :))) :)
Здравствуйте, VladD2, Вы писали:

VD> достоин попадания в аналы истории.


Супер!!!
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[3]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 13:00
Оценка: -1 :))) :)
AVK>что будет больше, выигрышь от улучшения языка или проигрышь в поиске программистов
AVK>И это, конечно, не бестолковые индусы, это просто люди

Позволю себе исправить орфографию.

Правильно писать не "бестолковые индусы", а "безграмотное московское жлобьё".
Re[7]: Что меня не устраивает в МП в Nemerle
От: yumi  
Дата: 28.12.08 03:46
Оценка: +3 :))
Здравствуйте, mihailik, Вы писали:

M>1) $

M>2) "
M>3) :
M>4) $
M>5) "

M>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.


$"Output: $a"
string.Format("Output: {0}", a)


Ну ':' ты зря посчитал, это элемент строки, а не спец. символ. Итого будет 4 спец. символа. Давай по аналогии посчитаем количество спец. символов в шарпе:
1. '.'
2. '('
3. '"'
4. "{"
5. "0"
6. "}"
7. """
8. ","
9. ")"

Итого 9 против 4-х, Шарп то, поклиничнее будет

А если по делу, то там ведь всего один спец. символ '$' и концепция стоящая за ним, проста как две копейки. Человека который не сможет понять такое я ни на одном проекте не встречал, если вам приходится работать с такими людьми, то мне вас искренне жаль.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[9]: Что меня не устраивает в МП в Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 27.12.08 21:22
Оценка: 44 (3) +1
Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.


VE>Все рождены в равенстве и с равными возможностями!


Я же вроде уточнил, что говорю о данном случае?

Я правильно понимаю, что это сейчас было утверждение "метапрограммистами не становятся, ими рождаются"? Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого. Научить же передавать через рисунок свои чувства (а тем более, чувства других людей), практически нереально, этому необходимо учится самому, имея некоторый врожденный фундамент и желание/стремление. Восприимчивость к такого рода самобучению и называют талантом. Так вот, освоить МП — это как научиться использовать новую технику в рисунке. Никаких талантов для этого не требуется, чистый формализм и механика. А вот то, как художник/программер эту технику будет применять в своих работах — это уже формализм совсем не всегда. Но и тут никаких новых талантов, кроме тех, что у хорошего художника/программера уже есть, и не нужно.

Забавно, пока писал про техники, вспомнил, как мы осваивали в школе на уроках живописи, одну из оных. Ее суть сводилась к следующему: в качестве холста для работы выступал кусок оргстекла, нужного размера. Рисунок наносился на стекло кистью, с использованием крайне размоченной на палитре акварели (точнее даже, воды с небольшим добавлением акварели), очень крупными и весьма условными мазками. После этого, холст (мы использовали ватман) обильно пропитывался водой и нашлепывался на это стекло. Сверху ложился еще один кусок стекла, и весь этот бутерброд придавливался чем-нибудь тяжелым (чтобы холст не покоробило от влаги). Когда краска высыхала, холст отдирался от обоих стекол и, сначала просто влажной кисточкой, а потом пером с тушью уточнялись контуры рисунка, смазанные из-за водянистости техники и смещений холста при нашлепывании.

Работы, выполненные этой техникой, получались безумно красивые воздушные, легкие цвета, плавные переходы оттенков, интересные артефакты и фактуры из-за неравномерной концентрации красок, которые потом можно было обыграть дополнительной тушевкой и контуром. И это при том, что общая композиция рисунка оставалась практически в полном соответствии с задуманной.

Эта техника отличалась от всех остальных, ранее нами изученных, в т.ч. и следующим:

1. Позволяла крайне быстро получить работы необычайной красоты и выразительности
2. Основной базис для рисунка со всеми его богатыми фактурами и переходами выполнялся не художником, а другим, более огрубленным рисунком, нанесенным заранее на стекло.
3. Овладение пером и навыками уточнения контуров хоть и потребовало некоторое время, но результат того стоил однозначно
4. Концентрация творческой составляющей, преимущественно на последней стадии позволила целиком и полностью посвятить себя на ней передаче своих эмоций, а не размазывать этот процесс по всем этапам, как в других техниках.

Вот и с чего это я про нее сейчас вспомнил?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[7]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 01:44
Оценка: 21 (3) +1
Здравствуйте, alvas, Вы писали:

A>1. Нужен road map. Если он есть — можно ссылку?


Можно даже без ссылок, а прямо inline-ом.
Роад-мап очень простой. В ближайшее время будет выпущена версия 1.0. Произойдет это после того как я доведу работы по поддержке LINQ до финала и после того как мы вычистим основные ошибки в компиляторе и интеграции.
Я надеюсь, что эта работа будет завершена в Январе. В крайнем случае в первой половине 2009-года.
Новых фич при этом добавляться не будут. Только если библиотеки разработанные сторонними авторами. Так возможно мы увидим библиотеку поддержки XML а-ля LINQ to XML и (опять же возможно) реализацию макры аналогичной фиче dynamic из C# 4.0.

A>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт. Огонь и движение

A>

A>Microsoft ведёт по вам огонь, и это всего лишь огонь прикрытия для того чтобы они могли двигаться вперёд, а вы нет.


A>Пример — необходимость реализации поддержки Linq в Nemerle.

A>На очереди dynamic, ...

Что-то в этом эссе есть. Но Джоиль человек не традиционной ориентации в прямо и переносном смысле этого слова.
Я не разделяю его вглядов. По крайней мере не все или не на 100%.

Так я считаю, что МС ведет этот огонь не со зла. Это проблемы большой организации и борьбы за лидерство в ней. Я тут скорее согласен с Роном Барком рассуждавшем о фатальном недостатке — его писали не они.

Посему и результат борьбы кланов в МС тоже неоднозначный. Например, создание Linq я считаю выдающимся достижением. Облачить ФП в столь понятную многим форму, да еще решить на его основе проблему интеграции реляционных данных и языков программирования общего назначения — это действительно прорыв который достоин попадания в аналы истории. В прочем, идея в основном заимствованная у Хаскелевцев, но даже факт доведения ее до масс является выдающимся достижением.

Посему считаю, что Linq должны поддерживать все уважающие себя гибридные языки реализующиеся на платформе дотнет (да и не только).
К тому же поддержка Линк не так сложна. Скорее сложно было довести систему разрешения перегрузок Немерле (действующую в очень жестких условиях отложенной типизации), чтобы быть совместимыми с библиотекой входящей в .NET Framework 3.5, нежели с самим Query Pattern. Само же преобразование кода в деревья выражений вообще было реализовано на базе макросов. Так что МС напряг не очень сильно своим Линком. Но он заставил довести систему разрешения перегрузки до очень высокого уровня.

A>Я так понял тут уж ничего не поделаешь.


Ну, почему же не поделаешь?
Вот погляди на ситуация которая складывается сегодня...
Все новые фичи C# 4.0 (до выхода которого еще 1.5 года) уже поддерживаются Nemerle. Разве что dynamic реализован не в полной мере и не через DLR, а через рефлексию. Но ведь, черт побери, реализован! И это было сделано 2 года назад! То есть мы опередили огромный Майкрософт ах на 4 года! Это ли не успех?
И так почти по всем новым фичам МС. Даже Линк — это проявление ФП которое было в Немрле с рождения.
Ко-/контр-вариантность интерфейсов и делегатов уже давно поддерживается в Немерле.
В общем, Немерле уже поддерживает все то что будет не только C# 4.0, но и в C# 5.0 (ведь компилятор изначально доступен как компонент, МП не просто реализовано, а реализовано как базовая фича языка).

Таким образом мы обогнали MS (который, на мой взгляд, движется в правильном направлении, но уж очень экстенсивными методами и с огромным количеством ошибок) на много лет. Эта фора которую нужно не прое... эээ... не утртить .
Все что нужно языку на сегодня — это отсутствие багов в языке и IDE.

Кроме того нужно:
1. Более качественное IDE. Желательно безупречная. Но это большая работа, особенно в условиях когда сама IDE основана на COM.
2. Вести работы над упрощением API компилятора используемого для целей мета-программирования.
3. Написать множество стандартных макросов которые можно будет использовать как строительные блоки.
4. Ускорить работу генерируемого им исполняемого кода. А это значит, что нам нужно научить его инлайнить хотя бы базовые ФП-функции вроде Map, Fold, Zip и Filter. А так же локальные функции и лямбды передаваемые в них. В идеале же нужно использовать технику супер-компиляции которая бы позволила максимально устранить, что называется, performance penalty от использования ФП.
5. Ускорить работу компилятора. Отчасти это сделает пункт 4, но кроме того компилятор нужно сделать многопточным. Чтобы он мог масштабироваться за счет увеличения процессоры ядер.
6. Возможно нужно снять ограничения на то где может применяться макрос и из каких лексем он может состоять. Тогда даже разбор самого описания макроса можно реализовать по средствам макроса, а ДСЛ-и можно будет объявлять на уровне типов.

Вот только все эти пункты мы будет реализовывать во второй версии языка и компилятора. Перед этим нам придется произвести основательный рефкторинг компилятора. Разбить его на модули абстрагируемые интерфейсами. Разложить все типы по отдельным файлам. Дать более внятные имена некоторым типам.

A>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если

код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

Гарантия отсуствия ломающих изменений, по крайней мере серьезных — это бутсртипинг компилятора, т.е. то что компилятор компилирует сам себя. Это приводит к эволюционному его развитию. Без ломающих изменений вряд ли получится улучшить язык. Но я уверен, что они не будут очень болезненными. Скажем переименование АПИ — это ломающее изменение. Но без него не обойтись. К тому же можно постараться сохранить и старые названия пометив их как obsolete.

Что касается стандарта, то тут нужны добровольцы которые будут его создавать. Я вряд ли потяну это, так как и так много дел, плюс мой английский для этого не годится.

A>4. Больше информировать комьюнити что происходит в Команде Nemerle.


Постараемся.

A>ЗЫ. Я так понял что не получилось у грандов выбить гранты — так разместите "Donate" на сайт и к вам потянутся люди.


Кто бы этим занялся. Просто невозможно сделать все сразу и в одиночку. Нас мало и приходится тратить время на основную задачу — доведение компилятора до ума. Финишь уже близко, но надо работать.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 01:07
Оценка: 1 (1) +1 -2
Здравствуйте, AndrewVK, Вы писали:

Итак, автор темы, как я предполагал, нашел в первом же моем вопросе "А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка?" фатальный недостаток.

Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.
Приношу ему свои извинения. Это было сказано не со зла, а исключительно потому, что этот вопрос бы старательно обойден автором темы стороной. Я думал, что автор не знает данной тонкости, но это
Автор: AndrewVK
Дата: 26.12.08
сообщение меня убедила в обратно.
Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования.


Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.
Обратимся за разъяснениями к Википедии.
http://ru.wikipedia.org/wiki/Предметно-ориентированный язык программирования
Предметно-ориентированный язык программирования (англ. domain-specific programming language, domain-specific language, DSL) — язык программирования, специально разработанный для решения определённого круга задач, в отличие от языков программирования общего назначения, например C, или языков моделирования общего назначения наподобие UML. Например языки Postscript, SQL и др.

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

AVK>И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


Продолжим разбираться в терминах. Итак DSL-и делятся на внешние и встроенные.
Пример внешнего ДСЛЯ-я файлы спецификации YACC и LEX. Это независимые DSL-и описывающие грамматику и синтаксис некоторого (конкретного) языка программирования которые превращаются в код (на языке общего назначения) парсера и лексере с помощью отдельной (внешней) мета-программ. Внешним он является, так как не встроен в другой язык, а живет своей отдельной жизнью.
Внутренний DSL (EDSL или DSLE) живет внутри другого языка. Примером внутреннего DSL могут являться: регулярные выражения, LINQ-запросы, $-строки (Nemerle, PHP или Руби), всевозможные спецификации (например, спецификации O/R-отображения на основе пользовательских атрибутов) и многое другое.
Удобстово встроенных ДСЛ-ей заключается в том, что они могут тесно взаимодействовать с языком общего назначения (ЯОН) в который они встроены. Кроме того ЯОН поддерживающие разработку встроены ДСЛ-ей (такие как Немерле) мгоут значительно облегчать создание встроенных ДСЛ-ей.

Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.

Немерел как раз такой язык. Возможность задания нового синтаксиса — одна из базовых фич макросов. Новая же семантика достигается средствами мета-программирования. Макрос принимает в качестве параметров код в виде AST и позволяет сгенерировать код который будет подставлен вместо вызова макроса. При этом макрос может использовать входные параметры как для включения их в выходной код, так и для получения некоторой дополнительной формации. Например, макрос foreach (хотя это по сути не ДСЛ, но он отлично демонстрирует принцип) получает на вход код коллекции, код описывающий переменную в которую будет помещено значение текущего элемента и код тела цикла. Макрос получает информацию о типе коллекции и генерирует специализированный код для массивов, списков, пртерна этумератор и интерфейсов энумератор. Код тела цикла подставляется в генерируемый код. В результате мы имеем высокопроизводительные реализации циклов для часто встречающихся коллекций, плюс понятные сообщения об ошибках и возможность дальнейшего развития этого макроса. Так foreach кроме всего расширен возможностью сопоставления с образцом и фильтрации данных. Что, многие разобравшиеся с языком, находят очень удобным.
Точно так же можно делать и ДСЛ-и. Язык предоставляет исключительную гибкость для их реализации. На сегодня Немерле предоставляет одну из лучших инфрастркутур для создания встроенных ДСЛ-ей в статически типизированных языках. Конкурировать с ним могут только Лисп и Хаскель. Причем у Немерле есть серьезные преимущества перед обоими. В прочем, ТемплэйтХаскель испльзует очень похожий на немерловый подход.

AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


Короче не всегда быстрее и уж точно не всегда правильнее.
MPS, DSL Tools, Oslo — это как минимум не конкуренты Немерле хотя бы потому, что это средства создания внешних ДСЛ-ей.

Несомненно каждый подход имеет право на существование. Но только в области своего применения.
Скажем DSL Tools — это по сути средство создания визуальных моделлеров таких как UML, ER или диаграмм классов из VS.
Интересно, что Немерле может весьма эффективно применяться совместно с ним для генерации кода по модели. Обратное не имеет смысла. В общем, это разные инструменты которые можно использовать вместе.
MPS — это отдельная песня. Это RAD-средство создания внешних ДСЛ-ей. По возможностям от оно более ограничено нежели немерловые макросы хоят бы потому, что не может использовать мета-информацию о типах языка для которого производится генерация и тем, что MPS создает только внешние ДСЛ-и.
Но надо признать, что во многом MPS — это конкурент Немерле. Причем в отличии от других данный конкурент предлагает весьма интересные средства и подходы.
Осло — это вообще мутант предлагающий писать внешние ДСЛ-и на основе ХМЛ и весьма странных средств трансформации.

Короче, все перечисленные средства как-минимум не умеют делать то, что умеет делать Немрле. А по жизни являются узко специализированными решениями.

AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


Опять хочется задать автору вопрос.
Он действительно не знает о том, что кодогенерация используется не только в визардах, но и в куче других мест?
Или же он намеренно обманывает своих читателей пытаясь внушить им, что кодогенерация и выизарды — это близнецы-браться?

Да, несомненно. В визардах используется генерация код. И несомненно она там обычно очень примитивная. Но на визардах свет не закачивается.
Есть куча задач требующих генерации кода. И, кстати — эти задачи называются мета-программированием, как бы автор темы в это не верил.
Более того, зачастую нужда в визардах исчезает если мы имеем в своем арсенале мощные средства мета-программирования.
Так же пропадает и нужда в кодогенераторах.
Например, в проектах C# и VB.NET ресурсные файлы генерируются визуальным интерфейсом встроенным в VS. Он формирует ХМЛ-файл с описанием ресурсов. Но ХМЛ-файл нельзя использовать их программы. В программе нужно иметь код который прочел бы ресурсы из исполняемого модуля и представил бы их в удобном для программы виде. Для этого в VS придумали весьма кривое решение — Custom Tool. Это кодогенератор создаваемый на дотнет-языке и ассоциируемый (в реестре) с расширением файла. Когда Студия производит запись файла, она вызывает ассоциированный с ним компонент и тот генерирует код на нужном языке. Кривость данного решения очевидно. Ведь без студии мы не можем запустить данный генератор. К тому же создание такого генератора весьма не тривиальная задача.
Немерле позволяет создать макрос читающих описание ресурсов в ХМЛ и генерирующий классы-обертки которые становятся доступными даже в во время разработки. Данный макрос одинаково работает как при компиляции, так и в дизайн-тайме. При этом сложность создания такого макроса на порядок ниже нежели генератора на обычном языке, так как при этом используется вся мощь мета-подсистемы Немерле. Описанный макрос создал человек не являющийся гуру в Немерле. При этом ему понадобилось всего пара советов.

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.


Этот пункт я вообще понять не могу. С одной стороны требуется генерировать код, но так как это сложнее его написания вручную (кстати — это еще почему?), то мы просто отказываемся от генерации и пишем код вручную. Другими словами мы отказываемся от самой цели. Чудесный пример того как человек заблудился в трех соснах.

Возможно имелось в виду, что проще написать программу которая с помощью какого-нибудь StringBuilder-а и какой-то там матери сгенерирует нетривиальный код в виде строк?
Спешу заверить, что сгенерировать код с помощью квази-цитирования в сто раз проще. При этом доступна декомпозиция кода с помощью квази-цитат и вся мощь ФП, так как од по сути есть набор списков (дерево состоящее из списков).

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле.


Не "неверно", а 100%. Только причем тут АОП? BLToolkit — это типичный пример встроенного DSL предназначенного для описания и организации DAL (уровня абстрагирования доступа к данным) реализованного на основе техники мета-программирования. Только IT использовал не продвинутые средства мета-программирования Немерле, а дико низкоуровневый Sustem.Reflectin.Emit (т.е. генерацию IL-а). Это дико усложнило задачу. Так, что надо отдать должное мастерству и упорству IT который сумел создать такую мощьную библиотеку столь неудобными для этого и низкоуровневыми средствами.
Кстати, BLToolkit отличный пример DSL-я не реализвемого средствами перечисленных автором темы, идеологически более правильных (по его словам) MPS, DSL Tools и Oslo. Все дело в том, что BLToolkit нуждается в информации о типах конкретных структур данных, а это невозможно без специального API данные для которого генерируются компилятором. Для BLToolkit такими данными являются данные рефлексии генерируемые компилятором и доступные в рантайме. В Немерле все те же данные можно получить во время компиялции, что с одной стороны увеличит быстродействие, так как не надо будет компилировать код в рантайме анализируя структуры данных, а с другой стороны его было бы проще реализовать так как генерировать код по средством квази-цитирования в сто раз проще.

AVK> Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню:


Да не стоит. Собственно я знаю, что в задачи автора темы входила генерация типов по описанию хранимому в ХМЛ-файлах которое производилось во время развертывания приложения на сервере.
Это интересный подход, но его тоже можно осуществить на макросах если просто запускать компиляцию прикладных сборок во время развертывания. Точно так же делал и автор. Только он сначала генерировал код с помощью XSLT, а потом компилировал его стандартным компилятором C#.

AVK>инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Если речь идет именно об модификации скомпилированных сборок, то конечно Немерле тут не поможет. Однако, как раз модификация скомпилированых сборок обычно делается от бедности средств времени компиляции. Скажем такие стандартные задачи АОП как логирование, профилирование и добавление аспектов намного удобнее делать во время компиляции.

К тому же никто не запрещает использовать средства инструментирования и вместе со средствами мета-программирования, каковым является Немерле. Зачем же противопоставлять эти подходы?

AVK>P.S. Еще раз, если кто то в корне со мной не согласен, прежде чем бросаться писать возмущенный ответ и разгромить меня в пух и прах, обратите внимание на наличие и содержание дисклеймера.


Мы видели твой дисламер. Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).
Единственное с чем я могу согласиться в твоих словах — немерле не замена средствам модификации IL-а, или средствам интсрументирования. Но зачем же их противопоставлять. Ведь это разные средства позволяющие добиться как похожих (АОП), так совершенно разных задач. Средства инструментирования весьма ограничены в возможностях и сложны в применении. Они не конкурент мета-программированию. Наоборот, они могут отлично дополнять МП.

Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль. Ведь только в честных спорах рождается истина.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Что меня не устраивает в МП в Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 30.12.08 01:45
Оценка: 1 (1) +2 :)
Здравствуйте, eao197, Вы писали:

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


KV>>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.


E>Пи<censored>... Трындеж.


Ну, я ожидал, что это не будетт для данного форума чем-то из ряда вон выходящим

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 26.12.08 13:11
Оценка: +1 -3
Здравствуйте, AndrewVK, Вы писали:

AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.


+1, в этом есть смысл
Всё остальное — просто ни о чем. Резонёрство сплошное.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[2]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 26.12.08 13:36
Оценка: -2 :))
Здравствуйте, Lloyd, Вы писали:

L>Целиком и полностью поддерживаю по всем пунктам!


"А я еще больше люблю господина ПЖ!" (С)
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 13:17
Оценка: +1 -3
Здравствуйте, IB, Вы писали:

A>>В чем демагогия то?

IB>В том, что он передергивает практически каждое предложение и отвечает не на то что было написано, а на то что ему удобно.

Не надо грязи. Иронизирую — да, но нельзя не иронизировать над набором заблуждений и неверных трактовок терминов.
А демагогии в моих словах нет вообще. Ух где она есть, так это в словах АВК.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 19:06
Оценка: -3 :)
IT> Возьмём тот же $-макрос из Немерле и сравним со string.Format:

IT>$"Output: $a"

IT>string.Format("Output: {0}", a)

IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.

IT>Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции.

Я тебе открою глаза: ты сам две строчки выше написал пример макроса, который труднее использовать чем функцию.

7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.
Re[11]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 28.12.08 04:57
Оценка: +1 :)))
Здравствуйте, AndrewVK, Вы писали:

AF>>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle".


AVK>Перечитай название темы.


И что? Надо перечитывать, пока не перестану там видеть "МП" и "Немерле"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[7]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 22:33
Оценка: +4
Здравствуйте, Ikemefula, Вы писали:

I>До объективности тут как до небес — нет ни одной оценки сложности от тебя или от Влада.


Какая оценка сложности? Сплайс-строки воспринимаются на уровне здравого смысла, больше ничего не надо. Не говори мне, что глянув на них в моём примере ты не понял о чём речь.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 30.12.08 09:09
Оценка: +4
Здравствуйте, VoidEx, Вы писали:
VE>Пока что я не вижу массового въезжания программистов в идеи МП (хоть с трудом, хоть без), а про деньги МС и Блабов уже наслышан, но верится с трудом, нерелигиозен.
Странно. Лично у меня опыт на 100% обратный — т.е. я не припомню программиста, который не пробовал баловаться с метапрограммированием. Это прямо с 12 лет.
Я помню, что еще тогда удивлялся тому, что есть программисты, которые пишут программы, заточенные на совершенно конкретную структуру таблички в базе данных.
Ведь вместо этого можно сделать универсальную программу, которая будет читать метаданные и работать с любой таблицей!

Такие идеи постоянно посещают людей. То им хочется сделать универсальную доставалку любых данных из базы, то универсальную сохранялку любых объектов в XML, то универсальный генератор UI по метамодели. В моей деревне трудно найти разработчика, который не баловался генерацией кода.

Поэтому у "въезжания в идеи" с массовостью, имхо, всё ок. Помилуйте, да если 90% программистов эти идеи изобретают, то уж наверное остальным 10% их удастся хотя бы объяснить?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[17]: Что меня не устраивает в МП в Nemerle
От: minorlogic Украина  
Дата: 07.01.09 10:33
Оценка: +2 -1 :)
Здравствуйте, Ikemefula, Вы писали:

I>Еще одна банальность. Невозможно всем дать московские ЗП, проще перевести разработку в Москву и набирать людей там.


А где логика ? если платить в регионе московские зарплаты , то вы соберете всех специалистов. И из москвы к вам поедут , потому что проживание дешевле.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 18:13
Оценка: 3 (1) +1 -1
Здравствуйте, AndrewVK, Вы писали:

К сожалению, в этом рассказе, я не увидел две вещи которые вроде бы должны были присутствовать в данной теме.
А именно:
1. Я не увидел последовательный анализа проблемы.
2. Я не увидел ни одного конкретного слова про Nemerle (хотя вроде как ему и посвящена тема).
Посему не ясно с чем дискутировать.
Все что я могу — это разобрать разрозненные (на мой взгляд) высказывания и дополнить их или дать свои комментарии.

AVK>1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.


В двух словах этот пункт говорит — "Я против синтаксических расширений потому как людей надо учить".
Сразу возникают два вопроса:
1. А автор темы вообще знает, что макросы в Nemerle не обязаны изменять синтаксис языка? Есть:
* Макросы уровня выражений. Их можно использовать как обычную функцию, но при этом они могут делать значительно больше чем просто фунции, так как выполняются во время компиляции и могут получать доступ как компилируемому коду (и проекту), так и к любым ресурсом в системе. Например, $-строка в Немерле — это макрос который не изменяет синтаксис. Или пример макроса который позволяет в мгновение локализовать локализовать всю программу не возясь при этом с АПИ ресурсов.
* Макро-атрибуты. Это такие же атрибуты как и те что автор темы привык использовать в C#. Только во время компиляции можно вместо них выполнить некоторые действия с проектом или его отдельной частью (например, функцией). Например, макросы из файла DesignPatterns.n: ProxyPublicMembers, AbstractFactory и Aggregate позволяют автоматизировать использование соответствующих паттернов проектирования. Это позволяет не заниматься копипэстом, а декларативно описывать желаемый паттерн и получать его реализацию автоматически. Более подробно об этих макросах можно прочесть здесь. Другими примерами могут служить макро-атрибуты Memoize (позволяющий автоматически кэшировать результаты вычисления для заднных аргументов методов), http://nemerle.org/Record_macroздесь]Record (который позволяет не писать конструкторы вручную).
Создается впечатление, что автор или не знает об этом, или пытается намеренно скрыть такую возможность, так как эта информация вырывается из стройного ряда его изложения.
2. Рассказы о том, что люди плохо учат новый синтаксис — это страшилки для не посвященных. Реально макросы вводящие новый синтаксис упрощают реализацию тех или иных участков программы. Например, такие макросы могут заменять использование громоздкого паттерна на компактный и интуитивно понятный код. Тут даже за примерами ходить не нужно. Конструкции "foreach, using, lock" которые в C# являются встроенными в Немерле являются макросами. Все кто использовал эти конструкции могут представить как было бы неприятно жить без подобных фенечек. Но в языке есть далеко не все, что хочется иметь. Скажем конструкция аналогичная using очень часто нужна когда нужно что-то на время активизировать, а потом, при раскрутке стека отключить. Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.
Где здесь та самая кривая обучения о которой ведет рассуждения автор? Я ее не вижу. Конструкция очевидна, интуитивно понятна и не требует дополнительного описания. А не понятные можно просто не использовать. Это ни чем не отличается от классов и методов с непнятными названиями или от методов с тучей непонятных параметров. Просто там где сейчас уродливый код мы можем написать чистый и понятный код.
Скажу больше. Позиция автора — это чистой воды обман. Не знаю уж осознанный или нет, но обман. Кривая обучения не снизится если в проекте не будут использоваться новые синтаксические конструкции. Она повысится! Почему? Да потому, что обучается человек прикладной логике используемой в программе. А ее тем проще понять чем она проще. И если что-то можно выразить специальным синтаксисом значительно проще чем без него будет проще и понять.

AVK>При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.


Причем тут какой-то конкретный язык я так и не понял.

Времени нет. Так что продолжу разбор полетов позже.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.12.08 21:26
Оценка: 2 (1) +2
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>А то, что если понимания не возникнет, то и потребности в макросах на все случаи жизни у него не будет, и будет он писать в C#-like стиле, постепенно вникая в технологию, необходимость и целесообразность применения МП. И учитывая


Разумеется, представь, в C# они тоже так вникают, если человек не освоил интерфейсы, индексеры и итераторы, то странно ждать от него вникания хотя бы в МП не говоря про Немерле.

KV>

KV>По этой причине людям стараются дать технологии, которые не отнимают времени на освоение.


KV>я в упор не понимаю, почему это преподносится как аргумент против МП в Nemerle, когда он явно является аргументом "за"


Это ты решил, что Немерле не отнимает времени на освоение.

Нигде не заметил каких то соображений на счет простоты МП и Немерле.

Я же считаю, что дело обстоит совершенно иначе — МП можно давать после того, как у человека образуется хорошая база в .Net, а уже потом, когда появится хорошая база в МП только тогда можно давать Немерле.

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

Т.е. единства внутри сообщества Немерле просто не будет, будет внутривидовая борьба.

Что то похожее есть в Перле, идеология Перла поощряет волюнтаризм, и тоже самое с Немерле.

Например, на Перле есть вагоны тех, кто любят пользовать всякие неявные феньки.

Другие стараются пользовать наоборот, явные конструкции.

В итоге сообщество состоит минима из двух видов перлистов.

Выливается это в невозможность должным образом сопровождать перловые проекты.

В Немерле это будет в гораздо большем масштабе.

На C# я уверен, что где бы ни писался код, кем бы ни писался, я смогу его прочесть а стало быть и использовать.

С Немерле этой гарантии нет — сначала, прежде чем прочесть, надо выучить те макросы, которые нагородит конкретное сообщество.
Re[2]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 10:30
Оценка: +3
Здравствуйте, Gajdalager, Вы писали:

G>Не знаю правильно ли понял.. Например, если взять веб-сервисы и кодогенерацию по WSDL — удобнее сгенерировать код и потом править, чем использовать макрос Nemerle, который генерит классы во время компиляции и поменять что-то под собственные нужды довольно сложно. Я правильно описал проблему? Тогда +1.


Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова. А ведь это может произойти тогда когда детали будут забыты, что приведет к серьезнешим проблемам и тормозам в развитии проекта.
Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).

Так что этот пример — большой минус, а не плюс.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 18:28
Оценка: +1 -1 :)
Здравствуйте, VladD2, Вы писали:

VD>1. А автор темы вообще знает


VD>Позиция автора — это чистой воды обман.


Ясно. В лес.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[9]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 23:30
Оценка: -1 :))
Здравствуйте, AndrewVK, Вы писали:

VD>> Ну, ты просто гений! Я бы так не смог.


AVK>Да, ненадолго тебя хватило.


Ну, вот... и похвалить нельзя.
Сразу ищут в этом подвох. А я искренне восхищаюсь тобой. Вот IT сам справиться не мог. И я не смог. И никто не смог. А ты смог! Причем смог не просто разобраться, но и сделать верные выводы. Это дорогого стоит и позволяет рассуждать о предмете глубоко и интересно.

Да и как по другому? Ведь если не верить твоим словам, то придется подозревать тебя в том, что ты говоришь не правду. А это конечно оскорбительно и безосновательно. Так что приходится только верить и восхищаться.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 27.12.08 11:55
Оценка: +2 -1
Здравствуйте, alvas, Вы писали:

A>Ирония — да, оскорбление — нет.

Ну вот лично я такую иронию воспринимал бы исключительно как оскорбление. Тем более, что его прямо попросили от подобной "иронии" удержаться и он даже обещал это сделать.

A>В чем демагогия то?

В том, что он передергивает практически каждое предложение и отвечает не на то что было написано, а на то что ему удобно.

A>Если вы знаете о задачах автора, то можно более подробно. Все повествование завязано на них, но упоминание о них крайне туманно.

Там упоминание очень конкретно. Он по пунктам расписал как именно он видит использование МП на своих задачах и почему немерле тут не подходит.

A>А можно хамскую цитату?

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

A>И как это понимать?

А что тут не понятного? В способы ведения честного спора "ирония" не входит.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[6]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 20:17
Оценка: -2 :)
Здравствуйте, rameel, Вы писали:

R>Я как бы просмотрел последние сообщения IT, пример упомянутого макроса не нашел, или же имелся ввиду вот этот


R>
R>$"Output: $a"
R>string.Format("Output: {0}", a)
R>

R>но где здесь 5 спецсимволов и где здесь клиника?

Где там 5 спецсимволов, неясно.

Но вот код такой просто клиника.

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

Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.

Далеко ходить не надо.

Есть два цикла, for и foreach

Первый суть алгоритмическая структура для итераций, а второй это очень, очень, очень сложная штукенция.

использовать если бездумно, то проще foreach

А если хоть немного думать при использовании, то только этот цикл требует разъяснения чуть не всего что есть в .Net вообще.
Re[8]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 02:55
Оценка: :)))
Здравствуйте, rameel, Вы писали:

M>>1) $

M>>2) "
M>>3) :
M>>4) $
M>>5) "

M>>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.


R>Скажите мне, что это стеб А то невольно вспоминается разговор про синтаксический оверхед господина Губанова


Стеб или нет, но язык действительно птичий Write Only.
Re[5]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 05:41
Оценка: +3
Здравствуйте, mihailik, Вы писали:

M>7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.


Я тебе открою один маленький секрет, чтобы ты в дальнейшем не нёс подобной пурги. В Немерле практически нет ничего, чего не было бы в других языках. Его уникальность в интеграции всего лучшего в одном месте. В частности, сплайс-строки понятны, например, любому перл- или руби- программисту. И поверь мне, они не разделяют твоего мнения и у меня больше доверия им, как людям, пробовавшим вкус фрукта, о котором идёт речь.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 14:56
Оценка: :)))
Здравствуйте, rameel, Вы писали:

R>>>Да ну А обоснования будут?


I>>А надо ? Не мог бы ты еще больше текста скипать ?


R>А как же. Не рассматривать же в качестве объяснения "клиники" размышления про разницу между for и foreach


Я честно скажу — с трудом догоняю эти $. Я хорошо понимаю только то что легко проговаривать.

R>А почему не наоборот Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.


Потому что это будет обман будет.

I>>VladD2 сам объясняет через C# код и удивляется где же сложность.


R>Статья больше была расчитана на людей с C# бекграундом, будь она расчитана на другую аудиторию — были бы и соответствующие примеры


Я бы сказал, что для Немерле обязательно нужен очень сильный бекграунд хоть в чем нибудь.
Re[14]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.12.08 17:50
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

I>Как же он поймет если ты не хочешь прояснять и пояснять свою позицию ?


Извини, но я не знаю как объяснять такие вещи. Название темы абсолютно не допускает ни какого толкования. Там прямым и понятным русским языком сказано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[11]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 18:44
Оценка: +3
Здравствуйте, mihailik, Вы писали:

M>$"Output: $a"


IT>>Первый вариант довольно тупо реализуется в runtime через string.Concat.


M>Вряд ли кому-то после такого объяснения останется непонятно, зачем там доллары внутри и снаружи кавычек.


Думаю, что суть примера стала ясна всем с первого взгляда. В том числе и тебе. Но тебе же очень хочется поспорить, правда? Потролить чуток. Посамолюбоваться. Тут я бессилен.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 29.12.08 01:56
Оценка: +3
Здравствуйте, VladD2, Вы писали:

IT>>Бывает, бывает. Есть генерилки, которые вообще не заточены на автоматическую генерацию вроде Custom Tools. С ними нужно повозиться, указать все необходимые параметры и потом раз и сгенерировать. После этого сгенерированный код используется как обычный рукописный. Народ этим широко пользуется.


VD>Есть, пользуются... не спорю. Только это уродство.


Что-то из тебя какой-то неадекват попёр.

VD>>>Изменение модели.

IT>>Какой модели?
VD>Любая генерация кода подразумевает, что есть модель описывающая базовые данные по которой генерируются частности.

Генератор — это прежде всего инструмент. В качестве инструмента, я могу, например, взять редактор кода и одним глазом подглядывая в SQL на структуру таблицы перенабить эту таблицу себе в код. Дале я буду поддерживать полученный класс в ручную. Как я понимаю — это правильный путь. Но если я вместо ручной начальной набивки напущу на эту таблицу генератор, то это уже уродство. Так что ли? Но ведь ты не найдёшь ни одного различия между этими классами. Так какая разница?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.12.08 09:20
Оценка: +3
Здравствуйте, VladD2, Вы писали:

VD>Согласен. Скажу больше. У формат-стринга есть еще одно приемущество (в некоторых случаях) — она позволяет менять формат в рантайме.


VD>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:

VD>
VD>$"Rum-Coke: $(F2(10 / 3))"
VD>

А знак доллара выведется? Или он должен быть частью функции форматирования?

VD>Или тупо воспользоваться форматом.

Хм. А ты можешь пояснить, почему строки сделаны именно так? Как аналог перла?
Потому что мне, к примеру, кажется, что для внедрения на рынок дотнета выгоднее было бы починить проблемы String.Format.
Самый хомячковый вариант — заменить номера аргументов на сами выражения.
Тогда бы работало, скажем, вот так:
Console.WriteLine($"Rum-Coke: {price:2}");

Как бы и волки сыты, и яйцы целы. В том смысле, что MSDN годами воспитывает людей пользоваться форматными строками, и грех не использовать эти наработки.
(Я намеренно убрал выражение из строки — именно потому, что в реальных случаях скорее всего речь будет идти о биндингах к переменным)

VD>В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.

А без намёка на мою недалекость можно было обойтись?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Что меня не устраивает в МП в Nemerle
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.12.08 13:18
Оценка: +1 :))
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.


Пи<censored>... Трындеж.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.01.09 14:55
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

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


I>>>>>Архитектура и меняется рефакторингом, а у же потом вносится новый функционал. Но часто отделить рефакторинг от написания нового функционала просто невозможно.

G>>>>Значит вы неправильно делаете рефакторинг.

I>>>Просто ты постоянно пытаешься чего то додумать, вместо того, что бы спросить.

G>>Если вы думаете что невозможно отделить рефакторинг от написания нового функционала, то вы неправильно делаете рефакторинг.

I>Покажи пример неправильного рефакторнга.

Неправльный рефакторинг — тот который нарушает наблюдаемое поведение системы.
Re[3]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 17:34
Оценка: 37 (1) +1
Здравствуйте, AndrewVK, Вы писали:

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


В том-то и дело, что это не проблема макросов. Макросы всего лишь средство выражения твоих решений. Если твои решения сложны для использования в твоей команде, то неважно как эти решения будут реализованы. Как раз макросами наоборот можно выразить это проще и доступнее. Возьмём тот же $-макрос из Немерле и сравним со string.Format:

$"Output: $a"
string.Format("Output: {0}", a)

Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.

Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции. Это просто не имеет смысла. Если легче и понятнее использовать функцию, то используется функция. Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач, чем аналогичное решение без макросов. Те же сплайс-строки, приведённые выше не только проще в использовании и нагляднее, но они ещё и безопасней, менее подвержены ошибкам. И так практически всегда.

IT>> Ведь ни функции, ни макросы, ни ключевые слова сами по себе не вводят новых концепций, они их реализуют и являются всего лишь следствием, формой.


AVK>Я же уже вроде писал — ничего не имею против, если макросы используются для разработки языка в рамках, заданных well known стандартом. Ну так, чтобы я мог требовать знание этих концепций при приеме на работу, и иметь при этом шансы кого то нанять.


Ты не можешь требовать знания ваших внутренних концепций, которые реализованы в ваших внутренних проектах. Человеку придётся учится, а тебе придётся его учить. Это обычный процесс, который даже для опытных девелоперов занимает несколько месяцев, чтобы въехать во все детали проекта. А в большинстве случаев во все детали никто никогда не въезжает. Потому что нафиг не надо. Работает у соседа соседский код и хорошо.

IT>>В общем, сложность использования макросов надумана


AVK>Видишь ли, я про сложность использования макросов ничего не писал. Я про сложности, порождаемые их использованием. А использовать да, использовать их просто, не могу не согласиться.


Что-то ты меня совсем запутал. Использовать просто, но простота использования порождает сложность. Какую сложность? Я не понимаю.

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


AVK>Я тоже так думал. А на практике оказалось, что этот DSL приходится поддерживать постоянно. Если DSL этот — ключевое момент системы, это еще ничего. А вот если вспомогательный — сложно все таки мыслить концепциями генераторов, сложнее, чем просто писать целевой код.


Любой общий компонент требуется поддерживать постоянно. Точнее не постоянно, а поначалу пока он утрясается и потом, когда нужно подстроиться под новые функциональные требования. Это касается любого компонента. Макросы и DSLи не исключение.

IT>>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код.

AVK>Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?

Я подумал ты о Custom Tools. А в данном случае если студия генерирует, то пусть себе генерирует.

IT>>Это опять лишь домыслы. Генерировать код на Немерле не сложнее, чем генерировать текст.


AVK>Опять же, ты неверно понял. Я нигде не писал, что генерировать код на Немерле сложнее, нежели генерировать текст. Я говорил о другом — нередко проще вообще ничего не генерировать. Это все я написал к тому, что была у меня задача создания довольно сложной модели и ее реализации в условиях цейтнота. Тогда я справился при помощи кодогенерации, и очень быстро получил результат. Но теперь, по проществии нескольких лет, приходится признать, что на поддержку генератора я затратил больше усилий, чем если бы я ничего не генерировал с самого начала и просто рефакторил бы готовый код.


У тебя скорее всего precompile-time генерация. Так с ней всегда так. Легко получить первоначальный результат, а потом начинаются пробуксовки до полной остановки. Проблема в негибкости и в ограниченности возможностей.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re: Что меня не устраивает в МП в Nemerle
От: hi_octane Беларусь  
Дата: 29.12.08 03:19
Оценка: 37 (1) +1
Визарды, custom tools и даже не упомянутые паттерны проектирования и пост-билд утилиты вроде FxCop — расцвели только из-за полного отсутствия каких-бы то ни было средств МП в C#/VB.NET. Не уверен только насчёт DSL.

После нескольких месяцев программирования на Nemerle изменяются подходы, так что сравнивать кодогенерацию с МП как в Nemerle можно имея лишь приличный опыт именно с МП Nemerle.

По пунктам:

1) Разработчики использующие МП должны стараться писать так, что-бы программисты использующие их библиотеки про МП вообще ничего не знали. Тогда даже ленивому программисту будет легко их код использовать. Пример из нашего проекта:

Log.Write($"Обновление $(line.Group.Name) завершено.");


Выглядит как вызов статического метода. Программист который это использует может никогда не узнать что статический метод не вызывается вовсе, а вместо этого создаётся код, который через service locator'ы собирает все доступные из метода сервисы логгирования и каждому вызывает уже экземплярный метод Write.

2) Если насущная необходимость ограничить по максимуму — то можно создать класс или несколько с методами, которые разрешено использовать конечному разработчику. То что все вызовы во внешнюю систему делаются только через методы этого класса отследить средствами МП легко. Более того можно свой синтаксис довесить, который только разрешённые методы будет использовать. Можно даже нацепить аттрибут уровня класса вроде [Skill(Level=Junior)] и такой аттрибут может проверить что в коде не используется методов относящихся к более высокому уровню сложности.
Одна лишь разработка качественного DSL парсера может встать в задачку сложнее чем разработка целой кучи макросов, классов и т.п. А может и нет. Зависит от DSL.

3) С внутренним устройством например студийных визардов не знаком. Работал только с кодогенераторами вроде CodeSmith, LLBLGen, MyGeneration — так им какие шаблоны целевого кода скормишь, такие файлы и сгенерируют. Многие шаблоны генерации были бы просто не нужны, имей компиляторы .NET средства МП как в Nemerle.

4) Как и в 2) — всё зависит от DSL.

5) Задача интересная, но очень специфическая и все ограничения из столь краткого описания не ясны. Интересно, если бы прикладной код был написан на Nemerle (или на языке с МП как в Nemerle) и теми же макросами в методы были вставлены вызовы пустых методов из внешней сборки, а в момент деплоймента с сервера забиралась бы уже реальная/обновлённая сборка, выполняющая инструментирование, это не решило бы проблему?
Re[3]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 13:11
Оценка: 21 (1) :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Я тут уже мысль расшифровывал — вопрос не в принципиальной возможности или невозможности, вопрос даже не совсем технический, вопрос в банальном бабле. Ну то есть — в данном конкретном случае, что будет больше, выигрышь от улучшения языка или проигрышь в поиске программистов. Увы и ах, у меня нет никакой возможности формировать команду из элиты, приходится работать с тем, что есть. И это, конечно, не бестолковые индусы, это просто люди, у которых пока не наработан большой опыт. Они, конечно, со временем его приобретут, и буду не хуже тебя или меня. Но продукт то нужен здесь и сейчас.


Считаю ваш скептицизм с точки зрения бизнеса оправданным, но все равно неплохо выбрать в команде самого смышленого и дать ему задачу следить за технологическими тенденциями в свободное от работы время. А за это ему пообещать, что он не будет наказываться за опоздания на работу, например...
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[4]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 28.12.08 15:22
Оценка: 8 (2)
Здравствуйте, IT, Вы писали:

IT>В том-то и дело, что это не проблема макросов. Макросы всего лишь средство выражения твоих решений. Если твои решения сложны для использования в твоей команде, то неважно как эти решения будут реализованы. Как раз макросами наоборот можно выразить это проще и доступнее. Возьмём тот же $-макрос из Немерле и сравним со string.Format:


IT>$"Output: $a"

IT>string.Format("Output: {0}", a)

Кстати, а как предполагается локализовывать подобного рода строки?
Re[11]: Что меня не устраивает в МП в Nemerle
От: Undying Россия  
Дата: 31.12.08 05:55
Оценка: 3 (1) +1
Здравствуйте, VladD2, Вы писали:

U>>1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается.

VD>Я даже не знаю что можно сказать на такое. Кроме как домыслами это назвать больше никак нельзя (ну, если оставаться в рамках приличия).
VD>Ты без проблем сам запомнил все что нужно и процитировал прямо. Что тут еще запоминать?

В чем достоинство именования вроде string.Format? В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа. Если же я завтра захочу написать свой макрос аналогичный $ как мне его назвать? $my, $$, L, $my_macros, my, my_macros? Как назвать правильно непонятно, потому что за названием $ нет концепции. А это очень плохо, т.к. приводит к тому, что разработчики будут называть свои макросы как бог на душу положит, соответственно с интуитивной понятностью чужого кода придется попрощаться. Отсутствие концепции это и есть птичий язык, который можно только запомнить, а не интуитивно вывести.

U>>2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1.

VD>Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?

Вот при такой записи допустить ошибку необнаруживаемую компилятором практически невозможно:

"Некая константа: " + _.s(obj1) + ", " + _.s(obj2);

В отличие от сплайс-строк, т.е. идеала сплайс-строки не достигли, это минус.

ps
Вообще, если бы сплайс-строка выглядела примерно так:

string.Inline("Некая константа: {obj1:F2}, {obj2}");

То решение бы мне наверное даже понравилось, т.к. оставалось бы в рамках концепции шарпа.
Re[15]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.01.09 12:58
Оценка: 1 (1) +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Ага, на рынок труда берем так и влияем.

4>>Получается, что влияете, т.к. открываете вакансии для "минимально справляющихся".
I>Кто тебе такое сказал ? Не только к нам дубы идут на собеседование, представь.
Беря на работу "минимально справляющихся" вы увеличиваете спрос (вернее величину спроса) для низкокачественной рабочей силы, тем самым увеличиваете предложение низкокачественной рабочей силы. А учитывая что количество программистов со временем растет медленно, то вы в среднесрочной перспективе еще и снижаете предложение более квалифицированной рабочей силы.

Кроме того из ваши постов видно что вы находитесь не в Москве\Питере\Другом_крупном_центре_разработки_ПО, при этом штат у вас порядка 100 человек, что достаточно много (я, например в Ростове-на-Дону обитаю, у нас софтверных контор от 100 человек нету). начит вы играте значительную роль на рынке программистской рабочей силы в вашем городе.

4>>Это банально дешевле + высокая гарантия положительного результата.

I>Это так. Но только в краткоскрочной перспективе.
Как раз набор высококачественных спецов выгоден в долгосрочной перспективе. Любая ставка на качество в разработке ПО выгодна именно в долгосрочной перспективе. Можете даже не спорить, это статистика.



4>>когда получалось, что 5% вытягивают остальные 95%.


I>Это и ежу ясно. Только надо учесть всего несколько моментов

I>1. специалистов надо набрать
I>2. специалистов надо удержать
I>Набор всегда и везде делается из тех, что на рынке труда, а не абстрактных.
I>Удержание задача очень сложная, больше всего проблем составляют не конкуренты в городе, а города/страны с большим уровнем ЗП.
А платить деньги людям не пробовали?
А создавать условия работы?
А давать потенциал для развития?

I>Итого — готовый специалист которого ты будешь искать месяц-два-три как это делает IT запросто может взять и уехать в другой город или страну через год.

И такое бывает, но не все специалисты уезжают ровно через год. Кроме того берите семейных, им переезжать гораздо сложнее.

I>Результат весьма плачевный — убыток из за отсутствия специалиста очень часто гораздо больше привлечения студентов.

Это только в краткосрочной перспективе. Кроме того можете создать условия, к торых вчерашние студенты будут учиться у опытных спецов. При этом поддерживать разумное соотношение между "спецами" и "студентами".

I>А вот крупные проекты это уже совсем другое дело. Удержать 5 и более лет специалистов уровня сеньора задача очень сложная, особенно когда в соседней стране такой может в короткий срок заработать на квартиру, вернуться обратно и даже открыть фирму.

Хм... повторюсь... А денег платить не пробовали?

I>Поэтому здесь имеет смысл заранее готовиться к текучке, которая будет независимо от того, хочешь ты или нет.

И единственный способ подготовки к текучке — набирать студентов?

I>Студент, у которого есть интерес к проекту, проходит все стадии роста. А уже через год может давать местами такие результаты, что угнаться крайне сложно.

И такой студент сразуже уходит на другую работу на большую ЗП.

Кстати вы сами писали что работали на проекте на котором за год пару раз сменился состав разработчиков.
Каким образом вы удерживаете людей когда набираете студентов, а текучка в год составляет чуть ли не 200%?
Re: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 25.12.08 20:37
Оценка: -1 :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Итак, сабж.

AVK>...

Целиком и полностью поддерживаю по всем пунктам!
Re[8]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 22:25
Оценка: +2
Здравствуйте, Константин Л., Вы писали:

AVK>>Лично я так не думаю, особенно если речь не об очень опытных разработчиках. Нет, изучить саму конструкцию, конечно, сравнительно несложно, а вот научится ее применять ... Та же ленивость нуждается в серьезном понимании.


КЛ>ты тут выше сам правильно сказал, что новые фичи, в основном, изучаются за счет личного времени.


Это когда фичи языка. А вот специфические языковые расширения в рамках коммерческого проекта — че то как то верится с трудом. Лично я бы на это собственное свободное время не стал тратить.

КЛ>то-же самое качается фреймворков


Конечно. Разница только в одном — в рамках. У немерлевых макросов они сильно шире, нежели чем у фреймворков. Поэтому и эффект намного сильнее.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[5]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 10:05
Оценка: :))
Здравствуйте, alvas, Вы писали:

A>Про


A>1. Design_by_contract прикручивается на раз. И иже с ним...

A>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
A>3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle?
A>4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет.
A>5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...

На все эти вопросы мой ответ содержится в корневом сообщении.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[3]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 26.12.08 11:11
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Правка сдегерированного кода — это пожалуй самое плохое что можно придумать. Ведь когда код будет перегенерирован все правки придется вносить занова.

Это если не удалось хорошо распилить код при помощи partial классов.

VD>А ведь это может произойти тогда когда детали будут забыты, что приведет к серьезнешим проблемам и тормозам в развитии проекта.

VD>Макрос же — это настраиваемая программа генерации кода написанная на высокоуровневом расширении очень высокоуровневого языка. Научить его генерировать код так как надо тебе не сложно. Править при этом ничего не придется. Если появляется задача изменить генерируемый код, то достаточно будет чуть-чуть поменять логику (например, добавить нужный параметр макросу).
Вот тут (см. выделенное) есть некоторые сомнения. В том смысле, что если у тебя возникает т.н. one-off ситуация, то есть что-то там нужно подшаманить ровно в одном месте, то это проще всего подшаманить ровно в этом одном месте. Подшаманивание генератора рискует дать труднопредсказуемые эффекты в других местах, где поведение уже отлажено.

Я не могу сходу придумать реалистичный пример, но нутром чую, что за ними дело таки не станет — только начни реальное применение. И AVK ровно об этом говорит. Генерировать код — нетривиальная задача.
Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.

И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[5]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 26.12.08 13:58
Оценка: +1 -1
Здравствуйте, AndrewVK, Вы писали:

AVK>ПОтому что не вижу иных причин называть резонерством описание того, с чем я реально сталкивался на практике.


То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?
Вах, я потрясен твоим опытом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[5]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 26.12.08 14:42
Оценка: :))
Здравствуйте, Serginio1, Вы писали:

AF>>>"А я еще больше люблю господина ПЖ!" (С)

AF>>>

L>>Кто это?

S>http://ru.wikipedia.org/wiki/%D0%A6%D0%B2%D0%B5%D1%82%D0%BE%D0%B2%D0%B0%D1%8F_%D0%B4%D0%B8%D1%84%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D1%86%D0%B8%D1%8F_%D1%88%D1%82%D0%B0%D0%BD%D0%BE%D0%B2

Не, гипотеза не верна. т.к. из нее с необходимостью следовало бы, что и перед Top 0 rsdn-а я тоже должен был делать "Ку", а это, мягко говоря не совсем так.
Re[8]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.12.08 17:58
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD> Ну, ты просто гений! Я бы так не смог.


Да, ненадолго тебя хватило.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 26.12.08 21:19
Оценка: -2
Здравствуйте, VladD2, Вы писали:

VD>Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос:

A>>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
Есть даже два.
Почему это не нужно конкретно AVK:

Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


Почему этого не стал делать MS, и почему это в принципе может быть не очень здорово:

На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.
При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.
Итого — внесение изменений в компилятор для улучшения языка лично для меня с точки зрения промышленного программирования малополезно (при этом побаловаться для проектов, рассчитаных на одну-две хари фо фан я как бы и не против).

... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[3]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 03:16
Оценка: +2
Здравствуйте, mihailik, Вы писали:

IT>>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.


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


M>Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?


К чему эта демагогия? Давай обойдёмся здесь без времён и англиских знакомых. Ты считаешь использование макросов сложным делом? Приведи пример, если сможешь, который демонстрирует эту сложность. Я со своей стороны попытаюсь приложить все усилия, чтобы понять в чём эта сложность состоит. АВК, кстати, привёл такой пример — yield return. Трудно видишь ли некоторым это понять. Согласен, трудно. А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.

IT>>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.


M>Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.


Не вижу логической связи между этими двумя утверждениями. Получается, что если макросы, то кругом одни тупые кодеры, а если MSDN, первый попавшийся у нас гений, способный одной левой разобраться с таким редкосным гауном как Custom Tools.

IT>>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.


M>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.


Директору может и всё равно, а начальнику IT департмента не всё равно. А если всё равно, то долго он начальником не будет.

M>Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".


Что-то тебя сегодня на демагогию прорвало. Солитёры, чемпионаты Думаешь это делает твои умозаключения (кстати, какие?) более убедительными?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Что меня не устраивает в МП в Nemerle
От: Andrei F.  
Дата: 27.12.08 04:46
Оценка: +1 :)
Здравствуйте, AndrewVK, Вы писали:

Ясно, значит, какой реальный опыт. Но я отвлекся.
Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[4]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 05:00
Оценка: +2
Здравствуйте, Andrei F., Вы писали:

AF>Например, возможность запретить использовать треды для низкоквалифицированных программистов. Или ограничение на unsafe-конструкции, как в C#. Или запрет обращаться к файловой системе и реестру напрямую в слое бизнес-логики. И т.д., и т.п.


Это не DSL. Это больше смахивает на FxCop.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 12:50
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Ну, вот... и похвалить нельзя.

VD>Сразу ищут в этом подвох. А я искренне восхищаюсь тобой. Вот IT сам справиться не мог. И я не смог. И никто не смог. А ты смог! Причем смог не просто разобраться, но и сделать верные выводы. Это дорогого стоит и позволяет рассуждать о предмете глубоко и интересно.

Остапа понесло. Молодец, ты прекрасно продемонстрировал причину, по которой я не отвечал на твои вопросы.

VD>Да и как по другому?


Действительно. Не нахамишь — день зря прожит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 19:21
Оценка: :))
I>>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.

VD>- Да дерьмо этот ваш Корузо.

VD>- По чему это?
VD>- Петька вчера напел.

Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.
Re[4]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 19:52
Оценка: +1 -1
Здравствуйте, IT, Вы писали:


IT>$"Output: $a"

IT>string.Format("Output: {0}", a)

IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.


Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.

Первый опускает все подробности, а программисту в голове по любому нужно держать их в голове.

Для объяснения "делает всякое со строкой" разумеется проще первый.

А вот для нормального использования надо знать все, что спрятано за коротенькой строчкой.

Попробуй объяснить это человеку, который не в теме и сразу поймешь в чем дело.

Второй пример без объяснений понятен любому, кто хотя бы пару месяцев осваивал программирование.

IT>Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач, чем аналогичное решение без макросов.


В том то и дело. Это и поднимает порог для входа.

IT>Что-то ты меня совсем запутал. Использовать просто, но простота использования порождает сложность. Какую сложность? Я не понимаю.


Ну примерно так -бинарный код самый простой из языков программирования он же самый сложный

Простота использования очевидна — пиши себе единицы и нули сколько влезет и как попало.

Сложность тоже очевидна — никому не ясно, что же там делается то.
Re[5]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 27.12.08 20:06
Оценка: +2
Здравствуйте, mihailik, Вы писали:

M>7 букв 5 спецсимволов -- это клиника. А приведённый код на C# понятен любому вменяемому программисту планеты.


Я как бы просмотрел последние сообщения IT, пример упомянутого макроса не нашел, или же имелся ввиду вот этот

$"Output: $a"
string.Format("Output: {0}", a)

но где здесь 5 спецсимволов и где здесь клиника?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[9]: Что меня не устраивает в МП в Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 27.12.08 20:11
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>Кроме того, если у разработчика возникнет понимание МП в Nemerle (а иначе как он придет к желанию покрыть макросами все его возможные потребности?), то он уже вполне может считаться "недебилом" и начать потихоньку писать их самостоятельно.


I>Ну, так, и что ?


А то, что если понимания не возникнет, то и потребности в макросах на все случаи жизни у него не будет, и будет он писать в C#-like стиле, постепенно вникая в технологию, необходимость и целесообразность применения МП. И учитывая

По этой причине людям стараются дать технологии, которые не отнимают времени на освоение.


я в упор не понимаю, почему это преподносится как аргумент против МП в Nemerle, когда он явно является аргументом "за"

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[8]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 20:42
Оценка: -1 :)
Здравствуйте, kochetkov.vladimir, Вы писали:

M>>Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.


KV>А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.


Желание и стартовая позиция. Лучше всего, когда профессию люди осваивают с глубокого детства, такие люди достигают максимальных успехов.

Технологии должны экономить время путем вовлечения в разработку безграмотных толп людей.

Если нечто этим свойством не обладает, то это не технология вовсе.

У них, безграмотных толп, гарантировано желания нет чего то осваивать и тем не менее это не становится преградой для распространения технологии.

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

Вот например, у нас на проекте работают

1 Тестировщики
2 Девелоперы
3 Алгоритмисты(это девелоперы но завязаные на очень узкую часть — алгоритмы которые придумывают математики)
4 Математики
5 специалисты по предметной области

интересы девелопера в математике отсутствуют, как и во всех других областях, а вот математики точно так же не имеют интереса кроме как в математике.
Ровно так же со всеми остальными.

Т.е. здесь имеет место вовлечение безграмотных масс в разработку, ибо должную подготовку по разработке ПО имеет только п.2.

P.S.

Вобщем то данный топик крутится вокруг одного вопроса — оценка сложности конструкций.

Игра приобрела такой расклад — одна часть считает что $"Output :$a" сложно, а вторая наоборот, считает что легко.

Как разрешить этот вопрос со сложностью — неясно.
Re[10]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 28.12.08 03:03
Оценка: +2
Здравствуйте, alvas, Вы писали:

A>Это проблема думать на Блабе
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.


Кстати, парадокс Блаба — сладкая самообманка для "элиты", потому-то её так и любят пользователи крутых (по всем параметрам крутых!), но непризнанных (возможно пока, хотя насчёт ЛИСПа уже почти и сомнений нет, у Немерле ещё всё впереди) языков, автоматически записывая остальных в Блабы, даже если понимают, что это не так.
И уж это чья угодно проблема, но никак не программистов, которые выбирают язык.
Re[5]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 04:36
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>А между тем, см. выше, без малого, 100% софта пишут безграмотные специалисты.


Ты бы довалял сразу "в нашей конторе", впрочем это уже и так не вызывает ни у кого сомнения.

В моей команде люди ищутся на место месяцами даже на второстепенные позиции. При этом человек может быть взят даже без интервью или с минимально формальным, если его хорошо отрекомендовал один из тимеров. Думаю, по количеству выполняемых проектов в среднем по нашей конторе нас должно было бы быть раз в пять больше. Объём кода, делающего тоже самое думаю тоже возрос бы во столько же, количество багов и сроки выполнения увеличились бы пропорционально. Безграмотных специалистов в нашей команде нет.

Это я к чему. 100% софта безграмотные специалисты пишут там, где это является стратегией компании. Примеров я могу привести мильён как из собственной практики, так и из практики друзей. Всё не так плохо. И не надо изо всех сил убеждать других в обратном.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 05:50
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

IT>>$"Output: $a"

IT>>string.Format("Output: {0}", a)

IT>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.


I>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.


Это обманчивое впечатление, которое базируется на знании и привычности второго варианта. Мне, например, в своё время казалось, что круче "Output: %s" вообще ничего быть не может. Оказалось может. А потом оказалось, что может быть даже круче того, что может быть круче первого. В общем, не надо путать свои привычки, предпочтения и желанием поспорить с объективностью. Сплай-строки реально круче, а при соответствующей подстветке в студии ещё и гораздо нагляднее.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 10:03
Оценка: +2
Здравствуйте, yumi, Вы писали:

VE>>Кстати, парадокс Блаба — сладкая самообманка для "элиты", потому-то её так и любят пользователи крутых (по всем параметрам крутых!), но непризнанных (возможно пока, хотя насчёт ЛИСПа уже почти и сомнений нет, у Немерле ещё всё впереди) языков, автоматически записывая остальных в Блабы, даже если понимают, что это не так.


Y>А это видимо сладкая самообманка для "мейнстримщиков", которые по каким-либо причинам не могут использовать действительно крутые языки


Это не самообманка, это реальность, которая такова, что массы, будь то девелоперы, будь то кто угодно, не хотят учить новое.

Посему никакой супермощный язык массы эти учить не станут, а именно на эти массы ориентируются все технологии, абсолютно все.

С мега-языками и мега-технологиями обычно так — на стартапе гуру применяет оные, а дальше, за его уходом, серые массы выбрасывают код этого гуру как только там понадобится чего доделать ну или костылями будут подпирать.

Потому мега-языки и мега-технологии для гуру живут на проекте ровно столько сколько и гуру, а нормальные, человеческие, переживают и по три раза смену всего состава тимы.

Т.е. массы признают технологию и пользуют, или не признают. В таких случаях, оправдание, как дырка в жопе, есть всегда и у каждого.

Вот например парадокс Блаба это как раз такое оправдание, что де серые массы не хотят учиться и думают на своем блабе.

Это же мышление на Блабе, что характерно, нисколько не мешает распространяться другим языкам и технологиям, а вот лиспы-немерли будут дохнуть.
Re[12]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.12.08 10:46
Оценка: +1 -1
Здравствуйте, Andrei F., Вы писали:

AF>И что? Надо перечитывать, пока не перестану там видеть "МП" и "Немерле"?


Нет, надо перечитывать, пока не поймешь смысл написанного.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 28.12.08 12:57
Оценка: -1 :)
IT>В общем, не надо путать свои привычки, предпочтения и желанием поспорить с объективностью. Сплай-строки реально круче

Вышел и чётко сказал: реально круче. Это тебе не какие-то предпочтения.
Re[20]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 28.12.08 13:21
Оценка: -1 :)
Здравствуйте, kochetkov.vladimir, Вы писали:

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

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

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

И правда, пора бы.
Re[10]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 14:03
Оценка: -1 :)
Здравствуйте, IT, Вы писали:

I>>Придется объяснять это так. А вот первую строку придется объяснять через вторую, как ни крути.


IT>Первый вариант довольно тупо реализуется в runtime через string.Concat. Алгоритм второго сложен и запутан. Что проще объяснить?


Ну вот, раз первый реализуется через string.Concat, то string.Concat проще для понимания.
Re[11]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 28.12.08 14:34
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

IT>>Первый вариант довольно тупо реализуется в runtime через string.Concat. Алгоритм второго сложен и запутан. Что проще объяснить?


I>Ну вот, раз первый реализуется через string.Concat, то string.Concat проще для понимания.


Офигительный вывод

Все-таки ветер дует не от того что деревья качаются, а то знаете ли, ассемблер тогда проще для понимания раз через него выражается все остальное, и код на нем прозрачен как слеза невинного младенца.

ЗЫ. ИМХО, этот топик пора уже в Коллеги улыбнитесь переносить, а то читать уже без улыбки невозможно
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[9]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 14:49
Оценка: :))
Здравствуйте, mihailik, Вы писали:

M>Как я тебя понимаю!


M>Но по-моему это не стёб, они всерьёз этот птичий клёкот $"output:"$" считают понятнее string.Format.


Эта хрень не проговаривается абсолютно, стало быть в общении между девелоперами использоваться не будет.

А раз общения не будет, то и распространяться будет медленно.
Re[5]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 22:38
Оценка: :))
Здравствуйте, Lloyd, Вы писали:

IT>>$"Output: $a"

IT>>string.Format("Output: {0}", a)

L>Кстати, а как предполагается локализовывать подобного рода строки?


Зачем?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Что меня не устраивает в МП в Nemerle
От: yumi  
Дата: 29.12.08 04:00
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

VD>Писать мета-код на С++ очень сложно. Понять его тоже весьма сложно. От того писать его могут единицы. Факт? Факт!


Твоими бы да устами... А то ведь пишут, читают Александреску и пишут...
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[22]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 29.12.08 13:01
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

VE>>Нет нет. "Наоборот" — это уже будет не доказательство. За что люблю детские вопросы типа "зачем", "почему", потому что они раскрывают, что тот, кто говорит, сам ничего не понимает, если до сути докопаться.


VD>Детям практически нельзя ничего объяснить серьезно. Как правильно заметил IT детям говорят, что "солнышко пошло спать", а когда они подрастут и поумнеют, им объясняют, что земля крутится вокруг солнца. За-то у детей есть доверие к взрослым. И если ребенку сказали что-то, то он это принимает это на веру.

Дети умнее, чем ты думаешь. Да и люди умнее, чем ты думаешь.
VD>Тут же получается глупая ситуация. Есть люди которые не в состоянии что-то воспринять по причине отсутствия базы и опыта, но на слово они не верят и требуют каких-то доказательств.
Нет, есть люди, которые сами не знают ответа, поэтому на вопрос детям "есть ли Бог" начинают мямлить всякую фигню типа "подрастёшь поймёшь", а взрослым — что у них нет базы.

VD>Ребята. Вам ничего доказать нельзя по причине отсутсвия базы. Идите наберите эту базу, а потом приходите и вам не придется ничего доказывать. Достаточно будет просто объяснить.

Ну-ка ну-ка. Какой базы? Религиозной? Веры в истинность некоторых спорных утверждений? Или что-то конкретное? Какой у нас базы нет? ФП, МП? Я гляжу, конкретики никакой, зато громких фраз много о том, что лучше, и ни слова о том, почему.
(И да, ты тут всех под одну гребёнку не равняй, я понимаю, что проще кучу человек в качестве некоего образа врага рассматривать, но я тут к сплайс-строкам например претензий не имею и меня интересовал только тот вопрос, который я задал)

VE>>Вот ты уверен, что лучше. Абсолютно уверен. Но не знаешь, почему. Для такого казалось бы очевидного утверждения нужно доказать, что хорошие спецы с новой технологией в целом обойдутся дешевле тысячи блабов. А в жизни куча примеров и первого, и второго.


VD>Я уже не уверен в том что помню о чем я говорил. Так как вся тема состоит из тысяч таких вот просьб обосновать.

Ну как же. Ты сказал, что лучше нанять поменьше умных программистов, чем бульоны блабов. Мне интересно, чем лучше? А оно оказывается надо в это поверить, иначе считается, что я не набрал базы, забавно.

VD>При этом свои абсурдные утверждения наши оппоненты обосновывать не считают нужным.

Это тебя оправдывает
Re[9]: Что меня не устраивает в МП в Nemerle
От: Undying Россия  
Дата: 29.12.08 13:09
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>Очевидно, тебе достаточно заменить все аргументы AddMessage одним вхождением сплайс-строки.


Хорошо, давайте теперь разберемся с плюсами и минусами такого решения:

Плюсы:
1) Некоторые ошибки форматирования станут невозможными, например, string.Format("Некая константа: {0}, {2}", obj1, obj2).
2) Более очевидный порядок переменных в строке.

Минусы:
1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается.
2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1.
3) Сложный вывод форматированных значений.

Также еще несколько вопросов:
1) Что будет если переданное макросу сплайс-строки значение равно null?
2) Как записать такую форматную строку: string.Format("{0}добавление")? Т.е. как макрос понимает, что имя переменной закончилось и началась строковая константа?
3) Как работает приведенное Владом: $"Rum-Coke: $(F2(10 / 3))"? В какой код эту запись развернет компилятор?

В принципе если сравнивать приведенные плюсы и минусы, то возможно плюсы и перевесят, хотя и несильно. Но проблема в том, что записи: TraceHlp2.AddMessage("Некая константа: {0}, {1}", obj1, obj2) и TraceHlp2.AddMessage($"Некая константа: $obj1, $obj2") неэквивалентны. Например, завтра мне понадобится лог локализовать. Что мне делать если я использую строку форматирования понятно — исходная строка форматирования становится ключом, по которому находится строка форматирования для нужного языка. А что я должен делать, если использовал сплайс-строки?
Re[11]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.01.09 08:42
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>Посему стоит брать не сильных людей, а тех, кто задержится подольше.

I>Разумеется, берётся человек, который минимально может справляться. При этом его уровень отстаёт от желаемого заметно.

Ну вот вы сами описали ваши проблемы. Получается не существует "вселенской тупизны кодеров", вы сами её локально у себя создаете.
Re[8]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 05.01.09 23:16
Оценка: -2
M>>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.

IT> Считовод, блин. А почему пробел не посчитал?


Считовод ты сам, блин. У тебя не спросил.
Re[10]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.01.09 18:21
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

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


I>>>А если у тебя МегаАрхитектура и требования не должны её ломать — извини, ты просто не умеешь делать рефакторинг.

VGn>>Я-то умею делать рефакторинг, а тот, у кого одна заплатка рвёт другую, скорее всего и не умеет.
I>При чем здесь заплатки, объясни ?

I>Вот придет заказчик и скажет, что в новой версии хочет видеть функционал который в предыдущих вообще не предусматривался.

I>Что ты ему ответишь ?
I>Это как раз тот случай, когда решение одной проблемы влияет на решение другой.
Нормальный product manager посовещается с разработчиками и скажет сколько такое будет стоит и в какой срок примерно будет готово.

I>А рефакторинг это как раз и есть способ разрешения подобных ситуаций.

Разберитесь в терминах. Рефакторинг — изменение кода с целью его улучшения без изменения внешнего поведения.
Ключевое выделено.

Так вот при реализации новых требований сначала надо провести рефакторинг, чтобы будущие изменения не затронули существующий функционал, а потом уже добавлять новый функционал. Это должно быть учтено в планах, сроках, ценах.
Кидаться править код по первому требованию заказчика — идиотизм.
Re[6]: Что меня не устраивает в МП в Nemerle
От: yumi  
Дата: 08.01.09 08:36
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

S>Я не готов делить шкуру ненаписанного кода. Возможно, ты и прав, но у меня нет никакой уверенности в том, что можно прямо вот так сесть и написать с первого подхода архитектурно красивый макрос.

S>Вот простое упражнение: берем существующий немерлёвый макрос sprintf и добавляем к нему умение читать не только тип данных, но и (опциональное) количество цифр после запятой.
S>Сколько это займет времени?

S>Теперь давай представим себе, что нас (прикладных разработчиков) везде устраивает тот вид sprintf, который был. И ровно в одном месте нам надо ограничиться одним знаком после запятой. Сколько времени заняло бы исправление сгенерированного кода?


Мда, меня всегда забавляли гипотетико-теоретики
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[25]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.01.09 10:06
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>>>Потому что для команды топов нужен топ-менеджер

G>>Так наймите такого менеджера. Он любых денег стоит в любом регионе.
I>Проще переехать в Москву, это не ко мне, это к руководству Там будет выбор и девелоперов и менеджеров.
Да вам уже десять раз сказали что не проще по многим причинам.

I>>>Но как правило, есть определенные слои — студенты например остаются надолго.

G>>Странно, почему так получается. По моим наблюдениям именно наиболее грамотные студенты очень быстро "растут" и их аппетиты меняются не соизмеримо с щедростью начальства.
I>И они тоже обычно работают больше года.
И каким образом их удерживают?

I>>>Есть определенная специфика отрасли, в основном наукоемкие десктоп-приложения, проектам в среднем лет по 5. Они не заканчиваются, разрабатываются версия за версией пока есть спрос.

G>>Такой тип проектов я называю "болото". Самый непревлекательный тип проектов для опытных разработчиков.

I>Опытные разработчики они разные, я бы не равнял всех по интересам.

I>Болото это когда технологии хорошо если девяностых годов — таких кстати говоря довольно много.
Ну а C++ каких годов? И какой интерес может быть в "болоте"? Разве что расширение своих занний в проедметной области, но такого интереса как раз на год хватает.

I>Въехать в проект я нызваю возможность более менее-полноценной замены одного из старых разработчиков.

I>А если разобрался с архитектурой, дизайном пары тройки подсистем — это до въезжания далеко.
Так это вообще другая величина. Такое "везжание" требует получения знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет.
Обычно под "въезажинием" понимают когда человек способен писать production-код в разрабатываемом приложении. При этом необязателньо он должен заниматься архитектурой и высокоцровневым дизайном.


G>>Хм... Зашел в статистику по ЗП, С++ средняя зп 1100$, вы платите выше на 30%-50%, те 1400$-1600$ грубо говоря. И это для не самых крутых разработчиков.

I>1100 на этом сайте довольно сильно завышена, правильно будет около 1000, в динамике можно глянуть, непонятно с чего в середине осени рост взялся.
I>Студенты обычно получают от 500. Год-два после универа — это 1000. Топы получают 2000 обычно.
I>Все что выше это уже стартапы и практически всегда серая ЗП.
Так всетаки мало платите, и ваши слова о 30%-50% ЗП выше среднерыночной — фикция.

G>>Топу вполне можно платить в 2 раза больше, потому что он реально будет работать за двоих, то есть 2800$-3200$. Получаются очень даже московские ЗП для топов.

I>Топы, которые в Минске получают до 3000 обычно в Москве или Ньюйорке берут куда большие деньги. Здесь ничего не меняется.
I>Топы в Москве не получают 2800-3200
Но не каждый получающий 3000$ в Минске или в любой_другой_не_мскве захочет поехать в москву.
Re[28]: Что меня не устраивает в МП в Nemerle
От: Курилка Россия http://kirya.narod.ru/
Дата: 08.01.09 13:18
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

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


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


G>>>Так это вообще другая величина. Такое "везжание" требует получения знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет.

I>>О чем и речь. То въезжание, о котором ты говоришь, и за въезжание не считается.
G>Это ты так думаешь. Я работал с десятками людей, которые успешно писали production код без полного въезжания в архитектуру системы в целом.

Есть версия, что, если для написания кода продакшн качества надо знать всю архитектуру системы в целом, то архитектура тогда не слишком модульно построена и в ней слишком много coupling (сцепления?)
Re[4]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 26.12.08 09:23
Оценка: 76 (1)
Здравствуйте, alvas, Вы писали:

A>>>Что подразумевается под словами "в моих задачах"?


AVK>>Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?


A>>>Я правильно понял?


AVK>>Странный вопрос. Не знаю я, как ты понял.


A>И вот как дальше обсуждать? Иду лесом...


Так как я не телепат , то буду рассматривать "в моих задачах" как "к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков"

Про

1. Design_by_contract прикручивается на раз. И иже с ним...
2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
3. "MPS, DSL Tools, Oslo" — еще один нужный (модный) ЯП, а может лучше "швейцарский нож"? Майкрософт всунула SQL в C#, так почему нельзя всунуть Oslo в Nemerle?
4. По поводу кодогенерации. Я считаю что МП в Nemerle не конкурирует с ней, а дополняет.
5. Если смотреть на МП в Nemerle как слишком БОЛЬШУЮ вещь, которую программерам лучше не давать — имеет слабую аргументацию. Уже вроде давно как доказан вред goto, но он есть в большинстве языков, в том числе и в недавно родившихся...

Контра

Если коротко — это отсутствие ECMA стандарта. Если есть желание обсудить — распишу более подробно и по пунктам.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[9]: Что меня не устраивает в МП в Nemerle
От: Константин Л. Турция  
Дата: 25.12.08 23:12
Оценка: 38 (1)
Здравствуйте, AndrewVK, Вы писали:

[]

AVK>Ну а куда деваться. Речь, впрочем, не о индусах, а о том, что у людей, вобщем то, разная квалификация и разный уровень оплаты. Не, я конечно не против, если бы у меня в команде работали исключительно асы, но опять все упирается в бабло.


AVK>Между индусами и мегапрофессионалами есть непрерывных спектр промежуточных вариантов.


есть, и этому спектру предлагают асиливать замыкания, правила overload resolution, контр/ковариантность. А вот атрибут навесить, который по сути макра, это сложно.

КЛ>> Вот, к примеру, RhinoMock. Нетривиально там все внутри? Так зачем мне знать, что там внутри? С макросами так-же.


AVK>Так, еще раз. Я говорю совсем не об этом. Я говорю о другом — любой новичек, каким бы он опытом не обладал, в проекте, широко использующем макросы, будет какое то время "индусом". Потому что ему придется изучить новый язык программирования.


Ок, давай отбросим макры уровня выражений. Отбросим даже те, которые синтаксис не меняют. Имеем синтаксис атрибутов. Этож почти как наследование. Добавил атрибут, есть в базе IXmlSerializable. Вроде ниче сложного. Писать будут сильные ребята из спектра, спектр тока атрибуты вешать

[]

AVK>В данном конкретном пункте я рассматриваю исключительно визарды, чтобы не смешивать мух и котлеты.


А в немереле генерация кода за счет использования квазицитирования и декларативности должна писаться еще проще. CodeDom по сравнению с ней — мамонт
Re[2]: Что меня не устраивает в МП в Nemerle
От: hi_octane Беларусь  
Дата: 27.12.08 10:02
Оценка: 38 (1)
M>Проблема немерле в том, что изумительная красота макросов пока никак не конвертируется в деньги.

Каждый свою success story имхо сам должен делать. Неважно в целом по жизни или в применении каких-то фич каких-то языков в какой-то предметной области. У кого-то вон milliondollarhomepage выстрелил — и success story офигительная и бизнес модель явно проще чем самое короткое описание пути конвертации yield return в деньги

M>Короче, вся эта крутизна пока не подтверждена убедительной success story.


Я Nemerle success story
Автор: hi_octane
Дата: 14.02.08
почти год назад выкладывал, и даже на вопросы отвечал. Проект тот и сейчас развивается.

M>А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?


Не обязательно сажать всю команду на неделю. Можно и пару самых динамичных людей посадить за какую-то не особо критичную часть проекта, а потом пусть расскажут всем что хорошее было а чего хотели но не было. А если команда не может выделить какой-то процент своих людей на исследования — то жить такой команде придётся на скучном саппорте устаревшего кода.

Как переходила на Nemerle наша небольшая команда
Автор: hi_octane
Дата: 18.02.08
я тоже писал. Кстати, времени отведённого на обучение фактически не было. Люди просто сели и начали писать — медленно и с точки зрения нашего единственного на тот момент функциональщика — косяча и через одно место. Но у Nemerle есть одно охренительное преимущество — не знаешь как сделать красиво — делай как на C# А потом функциональщик делал ревью и обьяснял — что здесь через одно место и здесь, и т.п. Да какой-то протормоз на этом получился, но мы как те мышки, которые кололись и плакали, но знали что катус колется только пока иголки не сгрызёшь. Так и вышло — сейчас у всех кризис-кризис, а нас заказчик развитием этого проекта загрузил по-полной.
Nemerle опыт применения success story
Re[13]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 12:12
Оценка: 9 (1)
Здравствуйте, Lloyd, Вы писали:

L>А префикс сплайса в L-строках все так же продолжит работать как и в $-строках?


Да. Но надо понимать, что это макрос, так что можно сделать так как тебе нравится.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 27.12.08 10:31
Оценка: 8 (1)
Здравствуйте, VladD2, Вы писали:

VD>Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.

Влад, ты задрал. На долго тебя действительно не хватило.
Я далеко не во всем согласен с АВК, да и задачи у меня другие, но наблюдать со стороны твою демагогию крайне не приятно.

VD>Ну, что же остается только задать вопрос: А почему же автор не упомянул о такой возможности? И почему он старательно пытается избежать ее обсуждения. Ведь, казалось бы, она снимает проблему изменения синтаксиса с которой боролся.

Не снимает. Проблема не в том, что можно так не делать, проблема в том, что так делать в принципе можно, об этом говорилось уже ни раз.

VD>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.

Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

VD>Из определения ясно видно, что это не усеченные или расширенные языки программирования общего назначения, а совершенно другие языки описывающие предметную область и оперирующие терминами из этой области.

То есть, ты утверждаешь, что переходя в термины предметной области ты не сужаешь набор возможностей? И не составит никаких проблем описать бухгалтерию точки общественного питания в терминах системы управления АЭС?

VD>Так вот поддержка ДСЛ-ей заключается не в наложении ограничений или расширений к основному языку, а в том, что язык позволяет описать совершенно новую семантику, а иногда и синтаксис.

С набором ограниченных возможностей.

[PR метапрограммирования поскипан...]

VD>Но ты почему-то проигнорировал наши просьбы дать расскзать о проблемах МП в Немерле. Вместо этого ты почему-то рассказал нам о своих предубеждениях (ни на чем не основанных).

Во-первых, никто не обещал рассказывать про проблемы МП в немерле, обещали рассказать чем не устраивает немерле именно AVK, и именно это и рассказали.
А во-вторых, рассказали на чем именно основаны "предубеждения".

VD>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.

А ты не хами и жалеть не придется.

VD>Ведь только в честных спорах рождается истина.

Возможно. Но только честно спорить ты не умеешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[4]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 27.12.08 15:52
Оценка: 8 (1)
Здравствуйте, VladD2, Вы писали:

VD>Кого я задрал?

Меня.

VD>С начало не плох было бы продемонстрировать демагогию в моих словах.

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

VD>Это не аргумент.

Для меня — аргумент.

VD> Запрети в своей конторе их использовать или дай разрешение на их введение только определенным лицам (т.е. себе любимому) и проблема исчезнет как класс.



VD>К тому же вам сто раз говрили люди которые все это используют на практике — нет проблем от синтаксических макросов.

На это сто раз уже отвечали, пойдем по кругу?

VD>Андрей просто неверно трактует термины встроенный DSL и мета-программирование. Об этом я и говорил.

Даже если это и так, то речь идет не о терминах. Все прекрасно поняли что именно он делает и почему для этого не годится Nemerle.
Если ты не согласен — у тебя есть два варианта:
1. Объяснить AVK, что на самом деле Nemerle для этого годится.
2. Объяснить AVK, для чего еще мог бы пригодится Nemerle в его задачах, тем более, что ты о них знаешь.
Вместо этого ты домотался до терминологии, что совершенно не существенно в данном контексте, это и называется — прикладная демагогия.

VD>Да, и это нужно четко понимать если уж ты взял на вооружение ДСЛ-подход.

VD>Ты не сужаешь и не расширяшь базовый язык.
Отлично. Ну, а AVK надо именно сузить, а нерасширить => Nemerle здесь не подходит, о чем он и написал.
Таким образом, мы выяснили, что AVK, знал о чем писал и правильно оценил возможности Nemerle. Как следствие, твои наезды совершенно беспочвенны, хотя возможно используемая терминология ввела тебя в заблуждение.

VD>Неужели это плохо?

Возможно хорошо, просто AVK это не нужно или не устраивает из-за побочных эффектов.

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

Он упускает из рассмотрения вещи, которые есму не нужны в его работе, о чем было ясно сказано.
... << RSDN@Home 1.2.0 alpha rev. 673>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[7]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 22:28
Оценка: 2 (1)
Здравствуйте, Ikemefula, Вы писали:

I>Да, представляешь, берем на работу студентов 3-4го курса. Наиболее перспективные кандидаты. Был случай, когда ст. 2го курса работал.


Т.е. кандидаты наиболее перспективные, но учиться уже не хотят? Как-то это не стыкуется.

I>В каком городе ты работаешь ?


В НуЁрке.

I>Ага, у вас все кандидаты наук, в какую область ни ткни, хучь медицина, хучь сопромат, так ?


Кандидатов в нашей команде нет. Нет такой необходимости.

I>И все при этом на ура знают любую часть девелопмента ?


Практически любую. Есть один индус, который занимается только SQL и Перлом. А так .NET, Web, UI, серверная бузинес логика, SQL. Каждый знает всё. И в этом есть один очень большой плюс. Узкая специализация, разделение работы горизонтально на UI, BL, DB требует постоянного взаимодействия между UI, BL и DB девелоперами. А это задержки и конфликты интересов, в худшем варианте перетягивание одеяла. В IBM я на это насмотрелся выше крыши. Специализация в софте плохо работает. Если в промышленности сталевар варит сталь, а фрезеровщик фрезерует фрезой, то их работа связана довольно чётким технологическим процессом, который в частности исключает взаимодействие этих парней между собой. В софтостроении исключить взаимодействие разных специализаций крайне сложно. В результате мы имеем постоянные нестыковки, бесконечные митинги, конфликты интересов, чем больше бумаги, тем чище жадница и прочую малоэффективную активность.

У нас разделение работы вертикальное. Один девелопер выполняет задачу от начала до конца. В идеале один девелопер — одно приложение. Естественно, стиль, общие компоненты, технологии используются одни и те же. Даже солюшин один на всех. Соответственно, я всегда имею возможность запустить чужой проект, при необходимости подправить там что-нибудь или подсмотреть.

Новые технологии, библиотеки изучаются по мере их появления и начинают применяться после их доступности в конторе на живых проектах, анализируется положительный/отрицательный опыт и принимается решение быть или не быть. Например, мы всё ещё в процессе поиска наилучшего решения для Web. AJAX от Microsoft, который UpdatePanel, был забракован после использования на одном проекте. Сейчас другой девелопер на другом проекте использует другой подход. Будет положительный результат, другие проекты тоже пойдут на этом фреймворке. Параллельно изучаются десктопно/браузерные альтернативы типа XBAP, WPF, Silverlight. И т.п.

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

I>С разработчкиками очень высокой квалификации сколотить команду можно буквально в паре-тройке городов. И то, как ты сам пишешь, месяцами искать людей.


Знаешь, когда мы были молодыми, то была такая ситуация, что и учиться было не у кого, не было ни интернетов, ни даже msdn'ов. И мы учились сами у себя. Буквально вчерашние студенты. Атмосфера была создана такая, что тяга к знаниям была у всех в команде. Постоянные обсуждения кто чего нового узнал, вау, круто, а если так и т.п. Все, буквально все тогдашние молодые специалисты из нашей команды стали хорошими инженерами с глубокими знаниями тех инструментов, с которыми они работают. И сегодня, кроме, конечно, тех, кто ушел в управление, любому за пол часа можно объяснить что угодно, если можешь объяснять, а он хочет слушать. Попробуйте у себя создать такую атмосферу, чтобы если даже ваши студенты шли пить пиво, то обсуждали между собой только новые технологии. И процесс обучения так пойдёт, что его трудно будет остановить. Они ещё тебя будут учить
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 25.12.08 21:44
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

A>>Что подразумевается под словами "в моих задачах"?


AVK>Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?


A>>Я правильно понял?


AVK>Странный вопрос. Не знаю я, как ты понял.


И вот как дальше обсуждать? Иду лесом...
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[4]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 21:58
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ>стоп. мне казалось, что ты имел ввиду косность мышления и тп. Какие нужны средства, чтобы сотрудники начали писать декларативный код с пом. линка, вместо циклов и массивов?


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

AVK>>Не очень понятно, если честно. При чем тут вольности? Выглядит как какая то эмпирика, а не истинная причина.


КЛ>Вольности, это клепать фреймворки и dsl-и на каждый чих


А, ну да, где то так.

AVK>>Почему не нужен? Не нужен глобальный прогресс в рамках конкретного прикладного решения, особенно если это решение не значительных размеров, не более того.


КЛ>при чем тут мп от немерле?


Не знаю. Это ты про прогресс спросил. Я просто ответил на заданный вопрос.

КЛ>при том, что они дают возможность отойти от стандартов.


Да нет, все гораздо печальнее — они подразумевают отсутствие зафиксированного стандарта вовсе. Разве что можно сформировать что то навроде СLOS. Но если есть возможность стандарт нарушать, то да, получаем то, о чем я писал.

AVK>>Ммм, а где в вышеприведенных технологиях интероп?


КЛ>ок, гарантированное отсутствие интеропа. этими тулами dsl не заканчиваются, правда?


Все равно мне непонятно, каким боком тут интероп.

AVK>>В случае C# есть partial types и partial methods. Визарды не предназначены для повторных вызовов, если такое требуется, то это уже п.1.


КЛ>какие у partial types есть инструменты для анализа окружения?


Никаких. Он не для этого нужен.

КЛ> В немерле для этого есть почти все.


Не в Немерле, а в его инструментарии, доступном в рамках IDE. Но это, согласись, совсем другой вопрос с совсем другим ответом.

КЛ>а тему все-таки надо было назвать "что меня не устраивает в МП в Nemerle для пром. разработки"


Слишкам многа букаф
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[6]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 22:06
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

КЛ> боюсь, что фича вроде итераторов, не то, о чем можно говорить в контексте денежных/временных затрат.


Лично я так не думаю, особенно если речь не об очень опытных разработчиках. Нет, изучить саму конструкцию, конечно, сравнительно несложно, а вот научится ее применять ... Та же ленивость нуждается в серьезном понимании.

КЛ> кроме того, каждый вменяемый манагер, принимая решение о переходе на ту или иную технологию, анализирует, что ему это даст в плане денег и времени. Так что кому выгодно — будут переходить, а невыгодно — тогда в чем вопрос?


В динамике. Код ведь потом поддерживать надо, а команды формируются не на всю жизнь. Нанимаешь нового разработчика, и, лыко-мочало, начинай сначала.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[5]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 09:35
Оценка: +1
Здравствуйте, alvas, Вы писали:

A>Если коротко — это отсутствие ECMA стандарта. Если есть желание обсудить — распишу более подробно и по пунктам.


Можно даже не спрашивать. Черт всегда скрывается в деталях. Так что расписывай. Тебе многие спасибо скажут.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 10:22
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>На все эти вопросы мой ответ содержится в корневом сообщении.


Серьезно?

Процитируй, плиз, кусок своего сообщения который давал бы ответ хотя бы на этот вопрос:
A>>2. Майкрософт добавила атрибуты в .Net, но не дала инструментов (или дала но слабые) для работы с ними. Поэтому нужно писать всякие прокси, так сказать свою виртуальную машину. МП в Nemerle решает эту проблему на отлично.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.12.08 17:18
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:


AF>>То есть ты реально пробовал всё это делать сам лично, причем с помошью Немерле?

AVK>Большую часть да, в том числе и с помощью Немерле.

И не разу ни к кому не обратился с вопросом? Ну, ты просто гений! Я бы так не смог.

AF>>Вах, я потрясен твоим опытом.


AVK>Ничего потрясающего в нем нет, чтобы просто побаловаться много времени не нужно. Когда то, несколько лет назад, еще до того как Влад тут всем начал МП пиарить, мне эта тема была интересна. Потом я интерес потерял.


Казалось бы причем тут Немерле?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 26.12.08 22:43
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD> Например, если вам нужно что-то закладывать в стек перед обработкой, а потом — это что-то вынимать, то вам придется пользоваться жудко неудобной конструкцией try/finally и при этом еще еще и каждый раз явно описывать действия связанные с финализацией. Меж тем можно написать макрос который автоматом выполнет нужные действия. Тогда вместо награмождения кода можно будет написать push_with_auto_pop(mySteack, value) { ... }.


Например в языках с развитой системой типов это делается обычной функцией. Зачем нужен макрос тут?
Re: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 02:03
Оценка: +1
AVK>Дисклеймер:

Проблема немерле в том, что изумительная красота макросов пока никак не конвертируется в деньги.

Круто, что foreach можно разъять на детали. Круто -- pattern matching. Круто полностью от начала до конца понимать, что такое монады (не гони пацан, это уже из "Что меня не устраивает в хаскелле").

Короче, вся эта крутизна пока не подтверждена убедительной success story. А без success story как ты промотивируешь команду сесть и вложить неделю времени в академические одиссеи?
Re[2]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 02:31
Оценка: +1
IT>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.

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

Например, многие мои знакомые англичане достаточно бегло говорят на английском языке и даже не спотыкаются на таких конструкциях как "will have been". Как ты думаешь, сложность использования времён в английском языке тоже надумана?


IT>Элементарно. Добавляем в проект атрибут-макрос уровня сборки и этот атрибут разгребает весь подходящий xml (или чего там) в проекте и генерирует код. Custom Tools понятное дело идут лесом.


Понятное дело. Более того, если через полтора года что-то где в этом отлаженом механизме чем-то накроется -- нужно всего лишь найти того программиста, который это написал, кинуться ему в ноги, заплатить хороших денег -- и проблема решена. Куда проще чем попросить первого попавшегося и сунуть ему в зубы раздел MSDN по Custom Tools.



IT>можно сказать, что да, написание макросов сложнее, чем, например, написание простого метода. Но ведь и эффект гораздо сильнее. Вообще написание библиотечного кода — это отдельный скил, который нужно тренировать.


Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.

Знаешь, в одной конторе провели чемпионат по Солитёру и всех трёх финалистов назавтра выперли. Так вот Солитёр не единственный непроизводственный "скил".
Re[8]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 03:28
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


A>>1. Нужен road map. Если он есть — можно ссылку?


Большое спасибо Но я думаю что на Nemerle.org это бы прочитало значительно больше людей.

A>>2. Команде Nemerle придется ВСЕГДА гнаться за Майкрософт.


Я не считаю что это Майкрософт делает со зла. Но Nemerle Team все равно придется дублировать все фичи МС. Спасибо что убедил меня в том что это не большая проблема для Nemerle Team.

VD>Кроме того нужно:


Вот это все нужно в road map

A>>3. ECMA стандарт даст гарантию невозможности ламающих изменений языка в мажорных версиях. Даже у Майкрософт если

VD>код считают устаревшим — помечают атрибутом [obsolete], но это ворнинги — код скомпилится без проблем. Обратная совместимость это наше все.

VD>Без ломающих изменений вряд ли получится улучшить язык. Но я уверен, что они не будут очень болезненными. Скажем переименование АПИ — это ломающее изменение.


Представь момент когда Nemerle стал мейнстримом. И что тебе скажут менеджеры проектов, когда после закачки обновлений прогибается код, написанный до этого? И плюс еще на сайте висит гордая надпись. "Переходите на 2.0, потому что мы через месяц прекращаем поддержку 1.0?" В общем я ничего не имею против ломающих изменений в бета, CTP, RC. Но мажорные версии должны полностью поддерживать возможности минорных. Иначе просто никто не рискнет использовать Nemerle в промышленных проектах.

PS. АПИ — это API? Я правильно понял?
PPS. Писали мы как-то один проект на .Net 2.0 бета. Говорю товарищу — а не опасно? Он — зато будем впереди планеты всей. Пришло время релиза .Net 2.0. Качнули, поставили. Прога запустилась. Ура! А тут сразу как полетели эксепшины. И что делать будем? Перекомплили исходники. И все заработало.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[6]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 27.12.08 05:21
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

IT>>Это не DSL. Это больше смахивает на FxCop.


AF>В рамках языка такая фича полезнее. Например, когда я работал на ABBYY, то познакомился с целым талмудом страниц на 100 — "как писать нельзя".


Ну дык не проблема. Пиши макрос-атрибут уровня сборки и пусть он бегает по коду и анализирует чего-кому можно, а кому нельзя. Например, в компиляторе есть макрос, который запрещает объявлять неизменяемые поля типа Location.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Что меня не устраивает в МП в Nemerle
От: FR  
Дата: 27.12.08 06:28
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

AF>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle". Выяснилось, что он не в состоянии вложить мозги в головы дураков и грамотно сделать проектирование вместо программиста. Действительно, фатальный недостаток системы МП


Популярность Лиспа, Dylan'а и Форта показывают что недостаток может и не фатальный, но очень существенный.
Re[4]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 10:03
Оценка: -1
IT> Трудно видишь ли некоторым это понять. Согласен, трудно.

Ты хотел пример, ты сам нашёл пример -- и сам видишь, что существование единичного примера ничего не доказывает.


IT> А ленивость в Linq не трудно? Проблема ведь та же, но ни одного ключевого слова там нет. Одни сплошные функции. Так в конструкциях языка дело ли? Тоже самое и с макросами. Макросы — это форма, такая же как и классы, методы, языковые конструкции. Настоящая сложность не в них, а в концепциях, которые они реализуют. Если в твоих проектах используются библиотеки общих компонент, то сложность их использования и сложность использования макросов будет абсолютно одинаковой. Никакой разницы.


Как противоречиво устроен человевеский мозг. Одновременно он может прекрасно понимать макросы немерле, и одновременно извергать такие зияющие логические противоречия.

НЕКОТОРЫЕ библиотеки сложны. Сложность использования НЕКОТОРЫХ библиотек сравнима с макросами немерле.


IT>Не вижу логической связи между этими двумя утверждениями. Получается, что если макросы, то кругом одни тупые кодеры, а если MSDN, первый попавшийся у нас гений, способный одной левой разобраться с таким редкосным гауном как Custom Tools.


Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.

60% студентов с улицы не осилят макросы немерле без посторонней помощи. Какие бы там ни были красоты внутреннего $.


M>>Директору конторы Васе Пупкину НУЖНА система расчёта, планирования и учёта километро-литров, ему с большим прибором на скилы которые там программисты тренируют в рабочее время.


IT>Директору может и всё равно, а начальнику IT департмента не всё равно. А если всё равно, то долго он начальником не будет.


Производственные проблемы уборщицы не должны тормозить работу фирмы. Если фирме нужны литры-километры в срок, то всё остальное должно следовать строго в фарватере.
Re[3]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 10:51
Оценка: +1
Здравствуйте, IB, Вы писали:

VD>>Он просто возмущен тем, что кто-то может сомневаться в том что автор может не знать что-то.

IB>Влад, ты задрал. На долго тебя действительно не хватило.
IB>Я далеко не во всем согласен с АВК, да и задачи у меня другие, но наблюдать со стороны твою демагогию крайне не приятно.

Ирония — да, оскорбление — нет. В чем демагогия то?

VD>>Хм. Весьма странные рассуждения. Они скорее запутают неопытного читателя нежели что-то ему объяснят.

IB>Позволю себе напомнить, что тут не стояла цель что-то объяснить неопытному читателю. Андрей объяснял, опытным читателям, что именно его не устраивает в Nemerle, на именно его задачах. И именно этого вы от него и требовали.

Если вы знаете о задачах автора, то можно более подробно. Все повествование завязано на них, но упоминание о них крайне туманно. К тому же на просьбы осветить этот вопрос автор отреагировал весьма странно
Автор: AndrewVK
Дата: 26.12.08
.

VD>>Почему-то уверен, что ответов по существу не будет. Вместо этого снова будет вцеплена одна из фраз, я буду обвинен в хамстве, а автор темы снова провозгласит себя правым и обиженным. А жаль.

IB>А ты не хами и жалеть не придется.

А можно хамскую цитату?

VD>>Ведь только в честных спорах рождается истина.

IB>Возможно. Но только честно спорить ты не умеешь.

И как это понимать?
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[2]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 12:09
Оценка: -1
Здравствуйте, Константин Л., Вы писали:

КЛ>можно разобью на 2?


КЛ>1. новые фичи осваиваются неохотно

КЛ>2. для пром. девелопмента лучше следовать стандартам, вольности неоправданы

КЛ>соглашусь частично только со 2м, тк если отталкиваться от п.1, то прогресс нафиг не нужен. макросы действительно хорошая штука, чтобы превратить код в кошмар. но я видел, как это делали используя обычные языки через жопу.


п.1 не означает что новое вводить не нужно просто нужно учитывать, что есть п.1 и никак без этого нельзя

Дело в том что комманды разработчиков меняются со временем и использование хлама вроде Неммерле существенно завышает входную планку.
Re[10]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 12:50
Оценка: +1
Здравствуйте, Andrei F., Вы писали:

AF>Ясно, значит, какой реальный опыт.


Перечитай дисклеймер.

AF>Резонерством я назвал потому, что это всё практически не имеет отношения к теме в заголовке — "недостатки в МП в Nemerle".


Перечитай название темы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[5]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 12:58
Оценка: +1
Здравствуйте, mihailik, Вы писали:

M>Студент с улицы самостоятельно разберётся с Custom Tools в течении 3 дней (в среднем), какие бы ни были там омерзительные названия методов и ключей реестра.


Названия методов и ключи реестра — это все незначительная шелуха. Гавенность Custom Tool глубже — он увязан со конкретной студией и увязан крайне нетривиально(слабо найти, к примеру, документацию, в каких случаях генератор запускается). Одна только необходимость коммитить генерируемый код — уже маразм еще тот.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[9]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 13:03
Оценка: +1
Здравствуйте, mihailik, Вы писали:

M>Нет, не так. Я сказал что макросы без посторонней помощи не осилить, а вы сказали, что красоты внутреннего $ это и есть макросы, и их можно за пару часов осилить.


Написание макросов — да, их использование — нет.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[4]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 13:17
Оценка: +1
Здравствуйте, alvas, Вы писали:

A>но все равно неплохо выбрать в команде самого смышленого и дать ему задачу следить за технологическими тенденциями в свободное от работы время.


Злостный оффтопик, ну да ладно. Неплохо конечно. Но мало. Во-первых, все, я повторяю, все программисты обязаны быть в курсе ситуации в их области, о тенденциях. Во-вторых, в определенном количестве контор в штатах (и даже в России) есть более интересный подход. При этом в рамках конторы (не из 5 программистов, конечно) создается команда высококвалифицированных спецов, которая постоянно держит руку на пульсе. В особо продвинутых случаях такая команда превращается в отдельный департамент.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[2]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 14:25
Оценка: +1
Здравствуйте, IT, Вы писали:

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


IT>Инженер, который не знает инструмента, с которым он работает, не может эффективно выполнять свои функции в принципе. С программистами, которые не хотят изучать новые технологии или даже противятся этому, рано или поздно начинаются проблемы из серии "тупой дизайн, кривой код".


По этой причине людям стараются дать технологии, которые не отнимают времени на освоение.

>Причём чем выше статус такого человека в команде, тем разрушительнее последствия. Я не знаю как эти вещи связаны между собой, может это чистое совпадение, но в моей практике это совпадение сто процентное, что позволяет мне сделать вывод, что оно не случайно. Для меня это даже стало очень чётким индикатором, человек не интересуется, не может освоить новое — ничего хорошего от него не жди. Под таких людей нужно не подстраиваться, а пытаться их учить, а если не получается, то постараться от них избавится.


Да, это хороший подход. Работает исключительно в коммандах из топ-разработчиков.

С плохими технологиями всегда так — чуть что, виноватые не создатели технологии, а тупые разрабы, потому что видители у топов все отлично.

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


Это тебе кажется, что не сложнее. А реально — много сложнее. Примерно на порядок.

У меня был случай, когда я понаписывал макросов а товарищи по проекту отказались их использовать и долбили копи-пастом.

Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.

IT>Главная проблема при изучении нового не в запоминании названия функций и конструкций языка. Главная проблема в освоении новых концепций. Тот же yield return не сложно запомнить, гораздо сложнее разобраться с ленивостью.


На этом срубается примерно 90% разработчиков, а остальные 10% рассматривать как целевую аудиторию для новых технологий как минимум несерьезно.

IT>В общем, сложность использования макросов надумана и не имеет ничего общего с реальной действительностью. Это не сложнее, чем использование метода из библиотеки общих компонент.


Сложности нет. Сложность в людях.

IT>А про правку сгенерированного кода и железной линейкой по пальцам тут уже сказали. И я с этим полностью согласен, т.к. встречался с таким баранизмом на практике.


Вполне возможно, что инструмент вышел немного не тот, что задумывался, потому за баранизмом надо искать проблемы, чего людям надо то.

IT>По первому пункту я уже всё сказал. Это не сложнее, чем использование классов, методов и атрибутов. Сложность не в макросах, сложность в концепциях, которые они реализуют. Но это в равной степени относится и к тем же классам, методам и атрибутам.


Это справедливо только для разработчиков топ-уровня.
Re[6]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 27.12.08 14:41
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>А как быть в том случае, если использовали макросы немерле? Исходника-то как такового нет.


VD>Макросы могут генерировать текст на который отображается отладочная информация.


Могут или генерируют?
Есть ли средства, позволяющие отследить, каким именно макросом был сгенерирована та или иная строчка?
Какой код генерируют? Если даже элементарные конструкции for/foreach/etc. — суть макросы, то будет ли этот конечный код читаемым?
Re[5]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 27.12.08 15:22
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>С новым инструментом надо решать вопрос — почему им смогут пользоваться дебилы.


"Дебилы" не смогут писать макросы, но они могут их использовать. В чем сложность использования макроса $ или foreach?
Не знаешь как писать? Пиши как на C# — hi_octane здесь
Автор: hi_octane
Дата: 27.12.08
доступно все описал.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[7]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 16:44
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:


I>Т.е. VladD2 понаписывает макросов на все случаи жизни ?


То есть, VladD2 не дебил, а это значит что он может написать мокросы которые нужны ему и другим.
Но это не значит, что только VladD2 не дебил. Таких людей много, а значит много кто сможет писать макры.
Скажем много кто пишет мета-код на основе шаблонов С++, но это ужасно сложно и неудобно. Но люди пишут. Писать мары на Немерле в сто раз проще. И значит их смогут писать куда большее число людей чем мета-код на С++ (например).
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.12.08 16:45
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

I>>>У меня был случай, когда я понаписывал макросов а товарищи по проекту отказались их использовать и долбили копи-пастом.

I>>>Во второй раз я решил проблему радикально — отказался от макросов и изменил фреймворк так что мои фичи использовались безо всякого геморроя.

Y>>Макросов на чем? Отказались по какой причине?


I>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.


— Да дерьмо этот ваш Корузо.
— По чему это?
— Петька вчера напел.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 27.12.08 17:21
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

VD>>Ну, что мы можем признать, что идеи макросов таки могут быть полезных хотя бы в каких-то областях?


AVK>А чего признавать то? Я обратного и не утверждал? Ты с кем споришь?


Фанаты ассоциируют себя с предметом фанатизма, а максималисты фразу "в МП Немерле мне нравится это" слышат как "МП в Немерле мне не нравится вообще, взять хотя бы это".
Вот мы и имеем, что имеем.
Надо было в дисклеймере ещё красными большими буквами написать, что кроме того, что не нравится, есть ещё и то, что нравится, хотя это и очевидно, но видимо не для всех.
Re[4]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.12.08 17:57
Оценка: +1
Здравствуйте, IT, Вы писали:

IT>В том-то и дело, что это не проблема макросов.


Я считаю, что все таки макросов.

IT>Как раз макросами наоборот можно выразить это проще и доступнее.


Все таки мы говорим об разных вещах. Я не про то, что макросами нельзя выразить доступно.

IT>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.


Ты неверно ставишь вопрос. Мне не нужно опытному программисту объяснять ничего про C# и BCL, он обязан это знать, на эту тему есть мильен книг и статей.

IT>Вообще я пока не встречал макросов, которые было бы труднее использовать чем функции.


Охотно верю.

IT> Это просто не имеет смысла. Если легче и понятнее использовать функцию, то используется функция. Обычно же, если появление макроса оправдано, то он решает куда более широкий круг задач


Да. Именно! Я как раз это и говорю — макрос мощнее и гибче обычного фреймворка.

IT>Что-то ты меня совсем запутал.


Ты сам себя запутал. Мои слова в исходном сообщении следует понимать буквально. Не стоит додумывать то, чего там нет.

IT> Использовать просто, но простота использования порождает сложность. Какую сложность?


Сложность вползания в сильно отличающуюся языковую среду, которая на долго живущем проекте обязательно будет эволюционировать в нечто уникальное. Эта проблема есть и сейчас, безусловно. Но, по крайней мере, сейчас это сдерживается рамками стандарта языка.
Если же урезать мощность макров с целью этого избежать, то, мне кажется, можно придумать какие то более простые решения, легче реализуемые, более дружелюбные к рефакторингу и IDE и т.д.

IT>Любой общий компонент требуется поддерживать постоянно.


Непонятно, опять же, с кем ты споришь. Конечно надо. Но генератор поддерживать тяжелее, чем код, который он генерит.

AVK>>Какой xml? Вот ты в студии выбираешь — добавить в проект новый класс. И студия генерит заготовку. Где там xml?


IT>Я подумал ты о Custom Tools.


Я уже заметил. Вобще, в этом топике каждый думает о своем, вместо того, чтобы внимательно прочитать, что я пишу. Я не столько на вопросы отвечаю, сколько опровергаю утверждения о том, что я говори то то и то то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[8]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.12.08 18:46
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>То есть, VladD2 не дебил, а это значит что он может написать мокросы которые нужны ему и другим.

VD>Но это не значит, что только VladD2 не дебил. Таких людей много, а значит много кто сможет писать макры.

Теоритически это так.

VD>Скажем много кто пишет мета-код на основе шаблонов С++, но это ужасно сложно и неудобно. Но люди пишут. Писать мары на Немерле в сто раз проще. И значит их смогут писать куда большее число людей чем мета-код на С++ (например).


Откуда взялись твои оценки сложности ? Здесь то и зарыта собака.

Разумеется, если разработчик в состоянии осилить такую глубину и большую, то ему будет легче. Речь то не об этом.

Судя потому, что люди плохо понимают виртуальные методы, интефейсы, индексеры, итераторы и эвенты, любое новшество это уже чрезмерное усложнение.
Re[10]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 19:25
Оценка: :)
M>>Какая разница?

AVK>Есть разница.


Есть?


M>>Если генератор детерменированый, пусть запускается когда хочет.


AVK>Главное, чтобы он запускался тогда, когда хочу я.


Легко -- правой кнопочкой и Run Custom Tool.
Re[4]: Что меня не устраивает в МП в Nemerle
От: hi_octane Беларусь  
Дата: 27.12.08 19:45
Оценка: +1
M>Из твоего рассказа я не очень понял, почему именно немерле и какую он бизнес-выгоду для проекта принёс.

Уже конкретный оффтопик попёр. Если продублируешь вопрос в той теме на которую я давал линку — отвечу.
Re[7]: Что меня не устраивает в МП в Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 27.12.08 20:11
Оценка: :)
Здравствуйте, mihailik, Вы писали:

I>>>Не важно на чем, макросы похожи на coroutines. Отказался потому что люди их не использовали, сколько бы я ни объяснял.


VD>>- Да дерьмо этот ваш Корузо.

VD>>- По чему это?
VD>>- Петька вчера напел.

M>Именно правильное сравнение. Пока Петька вчера напеть на немерле не может, будет он в пользовании только у Карузо.


А что есть такого у Карузо, чего не может быть у Петьки в данном случае? Ну, кроме отсутствия желания, разумеется.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[7]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 27.12.08 21:20
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

R>>
R>>$"Output: $a"
R>>string.Format("Output: {0}", a)
R>>

R>>но где здесь 5 спецсимволов и где здесь клиника?

I>Где там 5 спецсимволов, неясно.


I>Но вот код такой просто клиника.


Да ну А обоснования будут?

I>Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.


Студенту однофигственно придется объяснять что первое что второе. Причем, не факт, что первый вариант сложнее для понимания. PHP (да не в суе будет упомянут) тому яркий пример, там сплайс-строки умудряются применять и люди, знакомые с программированием лишь поверхностно.

Так что вопрос прозрачности больше тут связан как мне кажется с инертностью мышления и силой привычки
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[12]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 27.12.08 21:33
Оценка: :)
AVK>А если в солюшене файлов с custom tool несколько сотен?

Тогда потрать 10 минут и напиши програмулинку, чтобы вызывало. Обычно все Custom Tool имеют программируемый API.
Re[7]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 27.12.08 21:51
Оценка: :)
Здравствуйте, mihailik, Вы писали:

R>>но где здесь 5 спецсимволов и где здесь клиника?


M>1) $

M>2) "
M>3) :
M>4) $
M>5) "

M>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.


Скажите мне, что это стеб А то невольно вспоминается разговор про синтаксический оверхед господина Губанова

ЗЫ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[4]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 01:07
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Вот есть, допустим, автоматический генератор SQL запросов по некоторой модели.


S>И вот оказывается, допустим, что в одном из запросов тебе вынь да полож потребовалось, допустим, обратиться не к таблице, а к параметризованному view. Обучать генерилку поддерживать параметризованные view — дорого; это окупится только если таких view у тебя применяется много. В исключительном случае тебе проще будет руками поправить сгенерированный запрос.


Настоящая проблема precompile генерации не в том, что трудно писать генераторы, а в том, что precompile генераторами трудно, если вообще возможно гибко управлять. Т.е. вместо того, чтобы подойти к двери и прочитать табличку занято, мы начинаем ходить вокруг да около, заглядывать в замочную скважину и ждать пока оттуда кто-то выйдет или туда войдёт. Т.е. более менее сложная генерация должна делаеться на основе невнятных эвристик.

Для твоего примера в той же compile или run-time генерации можно для параметризации view задействовать, например, атрибут и добавить небольшую ветку в генератор, анализирующий этот атрибут в подходящем месте. Пользователь сам указывает, что он хочет, проблема решена, затрат минимум и главное никаких эвристик по вторичным половым признакам, что и делает эти генераторы сложными.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 02:22
Оценка: +1
Здравствуйте, rameel, Вы писали:

R>Да ну А обоснования будут?


А надо ? Не мог бы ты еще больше текста скипать ?

I>>Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.


R>Студенту однофигственно придется объяснять что первое что второе. Причем, не факт, что первый вариант сложнее для понимания.


Придется объяснять это так. А вот первую строку придется объяснять через вторую, как ни крути.

Вот например

http://www.rsdn.ru//article/nemerle/Amplifier.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.


VladD2 сам объясняет через C# код и удивляется где же сложность.

R>Так что вопрос прозрачности больше тут связан как мне кажется с инертностью мышления и силой привычки


У человека должны образоваться определенные причинно-следственные связи и только потом он сможет использовать новые знания.

На установление и разрушение оных нужно давать время. Это немного больше чем инертность мышления и привычки.

Такой инструмент, как логика, работает только там, где у человека правильные причинно-следственные связи.
Re[13]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 28.12.08 02:42
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

A>>Нужно переходить на следующий уровень мышления.

VE>Кому нужно? Кому нужно, чтобы большое кол-во программистов перешло на следующий уровень мышления?

Прикол в том что и не нужно. Nemerle имеет их несколько.

писать как на c# — блаб
в функциональном стиле — up
макросы nemerle — up
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[14]: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 28.12.08 02:56
Оценка: +1
Здравствуйте, alvas, Вы писали:

A>>>Нужно переходить на следующий уровень мышления.

VE>>Кому нужно? Кому нужно, чтобы большое кол-во программистов перешло на следующий уровень мышления?

A>Прикол в том что и не нужно. Nemerle имеет их несколько.


A>писать как на c# — блаб

A>в функциональном стиле — up
A>макросы nemerle — up

Nemerle — в отличие, например, от Хаскеля позволяет писать
и в импиритивном — "как в c#"
и в функциональном стиле.

Поэтому порог вхождения значительно ниже.
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[9]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 28.12.08 03:21
Оценка: -1
Здравствуйте, alvas, Вы писали:

A>Если использовать printf
Автор(ы): Владислав Чистяков
Дата: 09.12.2006
В статье на базе практических примеров разбирается что такое макросы Nemerle, что они могут и как их создавать.
вместо $, то


A>printf("Output = %d", a); // делает проверку типов параметров во время компиляции

A>string.Format("Output: {0:D}", a); // в рантайме


Слов нет. Более 200 строк на объяснение, как это работает.
А вот здесь 14 очевидных строчек. У Cayenne функция кушает меньше форматов, но в любом случае способ Nemerle шокирует по сравнению с Cayenne.
Re[5]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 05:27
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

IT>> Использовать просто, но простота использования порождает сложность. Какую сложность?


AVK>Сложность вползания в сильно отличающуюся языковую среду, которая на долго живущем проекте обязательно будет эволюционировать в нечто уникальное. Эта проблема есть и сейчас, безусловно. Но, по крайней мере, сейчас это сдерживается рамками стандарта языка.


Т.е. тебя не устраивает обилие возможностей. Т.е. главный недостаток МП в Немерле именно в его щироких возможностях?

AVK>Если же урезать мощность макров с целью этого избежать, то, мне кажется, можно придумать какие то более простые решения, легче реализуемые, более дружелюбные к рефакторингу и IDE и т.д.


Кастрированные макросы уже были в C, какой смысл повторяться.

AVK>Я уже заметил. Вобще, в этом топике каждый думает о своем, вместо того, чтобы внимательно прочитать, что я пишу. Я не столько на вопросы отвечаю, сколько опровергаю утверждения о том, что я говори то то и то то.


Ну так ты изъясняйся яснее. Сам знаешь, неясность изложения свидетельствует о путанности в мыслях. Мне действительно трудно уловить твои притензии к МП в Немерле.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 06:10
Оценка: :)
Здравствуйте, mihailik, Вы писали:

R>>но где здесь 5 спецсимволов и где здесь клиника?


M>1) $

M>2) "
M>3) :
M>4) $
M>5) "

M>Клиника: 5 спецсимволов на 7 букв. Птичий язык Write Only типа перла.


Считовод, блин. А почему пробел не посчитал?

Конечно же, PleasePrintWordOutputThenPutColonThenSpaceThenLocalVariableNamedAInLowerCaseThanks гораздо понятней. Кто бы сомневался.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 28.12.08 06:18
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

R>>Студенту однофигственно придется объяснять что первое что второе. Причем, не факт, что первый вариант сложнее для понимания.


I>Придется объяснять это так. А вот первую строку придется объяснять через вторую, как ни крути.


Первый вариант довольно тупо реализуется в runtime через string.Concat. Алгоритм второго сложен и запутан. Что проще объяснить?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Что меня не устраивает в МП в Nemerle
От: IB Австрия http://rsdn.ru
Дата: 28.12.08 09:01
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>У меня в конторе народ генерирует генератором Linq2SQL набор классов по БД, зачем вычищает оттуда весь мусор и уже далее поддерживает этот код вручную. В принципе, ничего плохого в этом нет. Небольшая автоматизации на начальном этапе.

Похоже большинство именно так и делает.. )
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
http://www.rsdn.org/File/343/537.gif Мы уже победили, просто это еще не так заметно...
Re[11]: Что меня не устраивает в МП в Nemerle
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 28.12.08 09:20
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>Я правильно понимаю, что это сейчас было утверждение "метапрограммистами не становятся, ими рождаются"?

VE>Разумеется. Ну т.е. становление тоже имеет место, но далеко не 100%, и даже скорее всего не 50. Захотеть тоже надо уметь. Гены сильная штука. В принципе можно и кролика научить курить (вопрос времени и денег), но вот есть люди, какие есть. Есть даже неспособные понять указатели.

Какие дополнительные таланты нужны программисту, чтобы освоить МП?

KV>>Я уже не раз приводил (в том числе и тут, в ФП) аналогию с рисованием. Рисовать можно научить любого.

VE>Если под рисованием понимать "возить кисточкой по бумаге", то да. И я даже не про передачу чувств, я просто про качественные рисунки.

http://www.rsdn.ru/Forum/?mid=3134534
Автор: kochetkov.vladimir
Дата: 11.10.08


KV>>Так вот, освоить МП — это как научиться использовать новую технику в рисунке. Никаких талантов для этого не требуется, чистый формализм и механика.

VE>И время и деньги. И способности. Вон тут монады некоторые понять не в силах. И таких наверняка большинство. А ключевое слово какое-нибудь присобачить, делающее то же самое — это поймёт почти любой. Вроде нет разницы, а вроде вот она.

Дело не в способностях. Ничего сложного в монадах, imho нет. Дело в костности мышления этих многих. Пытаясь понять какие-либо приемы ФП, они все еще мыслят категориями и понятиями ИП, т.к. эта парадигма прочно и наглухо засела у них в голове. Не думаю, что любой из этих многих, не освоил бы в т.ч. и монады, если бы стал изучать их до погружения в императивщину.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[13]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 28.12.08 11:04
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


VE>>>Кстати, парадокс Блаба — сладкая самообманка для "элиты", потому-то её так и любят пользователи крутых (по всем параметрам крутых!), но непризнанных (возможно пока, хотя насчёт ЛИСПа уже почти и сомнений нет, у Немерле ещё всё впереди) языков, автоматически записывая остальных в Блабы, даже если понимают, что это не так.


Y>>А это видимо сладкая самообманка для "мейнстримщиков", которые по каким-либо причинам не могут использовать действительно крутые языки


I>Это не самообманка, это реальность, которая такова, что массы, будь то девелоперы, будь то кто угодно, не хотят учить новое.

90% людей с которыми я работал хотели изучать новое. Но далеко не у всех было время на изчение чего-то кардинально отличающегося от существующего.

I>Посему никакой супермощный язык массы эти учить не станут, а именно на эти массы ориентируются все технологии, абсолютно все.

Если супермощный язык сильно не похож на существующий, то может и не станут. Но это не про Nemerle

I>С мега-языками и мега-технологиями обычно так — на стартапе гуру применяет оные, а дальше, за его уходом, серые массы выбрасывают код этого гуру как только там понадобится чего доделать ну или костылями будут подпирать.

Когда-то также говорили о C++, в последствии о Java и C#. А некоторые и сейчас так говорят.

I>Потому мега-языки и мега-технологии для гуру живут на проекте ровно столько сколько и гуру, а нормальные, человеческие, переживают и по три раза смену всего состава тимы.

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

I>Т.е. массы признают технологию и пользуют, или не признают. В таких случаях, оправдание, как дырка в жопе, есть всегда и у каждого.

I>Вот например парадокс Блаба это как раз такое оправдание, что де серые массы не хотят учиться и думают на своем блабе.
I>Это же мышление на Блабе, что характерно, нисколько не мешает распространяться другим языкам и технологиям, а вот лиспы-немерли будут дохнуть.
Да ну, приведите примеры других языков и технологий, которые активно распространяются без маркетинговой поддержки заинтересованных лиц?
Re[8]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 28.12.08 12:12
Оценка: :)
R>Скажите мне, что это стеб

Как я тебя понимаю!

Но по-моему это не стёб, они всерьёз этот птичий клёкот $"output:"$" считают понятнее string.Format.
Re[6]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 28.12.08 12:19
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Думаю, по количеству выполняемых проектов в среднем по нашей конторе нас должно было бы быть раз в пять больше. Объём кода, делающего тоже самое думаю тоже возрос бы во столько же, количество багов и сроки выполнения увеличились бы пропорционально.


Можно поинтересоваться, когда вы договариваетесь с заказчиком об используемых технологиях, вы говорите ему, что собираетесь в качестве основного языка разработки использовать язык, разрабатываемый на добровольных началах небольшой группкой русских программистов? Или тактично замалчиваете этот момент?
Re[9]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 28.12.08 12:41
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

R>>Да ну А обоснования будут?


I>А надо ? Не мог бы ты еще больше текста скипать ?


А как же. Не рассматривать же в качестве объяснения "клиники" размышления про разницу между for и foreach


I>>>Прозрачности в первой строке около нуля, как объяснить например студенту первого курса подобное — неясно. Вот она, сложность.


R>>Студенту однофигственно придется объяснять что первое что второе. Причем, не факт, что первый вариант сложнее для понимания.


I>Придется объяснять это так. А вот первую строку придется объяснять через вторую, как ни крути.


А почему не наоборот Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.

I>Вот например


I>http://www.rsdn.ru//article/nemerle/Amplifier.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.


I>VladD2 сам объясняет через C# код и удивляется где же сложность.


Статья больше была расчитана на людей с C# бекграундом, будь она расчитана на другую аудиторию — были бы и соответствующие примеры
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[9]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 28.12.08 12:41
Оценка: +1
Здравствуйте, mihailik, Вы писали:

M>Но по-моему это не стёб, они всерьёз этот птичий клёкот $"output:"$" считают понятнее string.Format.


О-о, такими стараниями и @"{0}" и "%s" можно называть птичим клёкотом и смело ставить C# на одну ступень с Perl, k и brainfuck

Верной дорогой идете товарищи (c)

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[7]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 28.12.08 12:56
Оценка: -1
Здравствуйте, mihailik, Вы писали:

IT>>В моей команде люди ищутся на место месяцами даже на второстепенные позиции.

IT>>Безграмотных специалистов в нашей команде нет.

M>Это здорово, что совсем безграмотных нет! Но если ещё сильнее отсеивать, то и грамотного можете найти.


Немерлисты, конечно, грешат безграмотностью (даже не знаю, есть ли связь, или совпадение), но тут ты умудрился снайперски попасть в идеально написанный пост. Да ещё и свою безграмотность заодно показал.
Re[8]: Что меня не устраивает в МП в Nemerle
От: mihailik Украина  
Дата: 28.12.08 13:06
Оценка: :)
VE>Немерлисты, конечно, грешат безграмотностью (даже не знаю, есть ли связь, или совпадение), но тут ты умудрился снайперски попасть в идеально написанный пост. Да ещё и свою безграмотность заодно показал.

Ищутся?
Re[10]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 14:47
Оценка: -1
Здравствуйте, yumi, Вы писали:

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


I>>Попробуй сюда написать разъяснения про первую строчку из примера IT.


Y>Все уже написано и не раз:

Y>1. String interpolation
Y>2. A little prize: string interpolation
Y>3. String interpolation i.e. $-notation

Y>Да и вообще, поиск рулит.


Ну, это круто. Сравни

String..::.Concat Method (String, String)

Concatenates two specified instances of String.

Namespace: System
Assembly: mscorlib (in mscorlib.dll)


Вот тебе и сложность.
Re[10]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 14:59
Оценка: -1
Здравствуйте, rameel, Вы писали:

R>О-о, такими стараниями и @"{0}" и "%s" можно называть птичим клёкотом и смело ставить C# на одну ступень с Perl, k и brainfuck


C# здесь точно ни при чем.
Re[11]: Что меня не устраивает в МП в Nemerle
От: rameel https://github.com/rsdn/CodeJam
Дата: 28.12.08 15:05
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Ну, это круто. Сравни


I>

I>String..::.Concat Method (String, String)

I>Concatenates two specified instances of String.

I>Namespace: System
I>Assembly: mscorlib (in mscorlib.dll)


I>Вот тебе и сложность.


Интерполяция строки позволяет автоматически подставить вместо переменной ее фактическое значение. (с) Кто-то другой


Это ведь так сложно понять
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 >>
Re[5]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 28.12.08 18:16
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:
IT>>Сравни и прикинь, что будет легче объяснить и где будет меньше ошибок как по незнанию, так и по невнимательности.
I>Я на полном серьезе считаю, что второй вариант проще. Кода больше, но он и сообщает много больше.
А я на полном серьезе считаю, что второй вариант очень сложный, но мощный. Я до сих пор путаюсь в format specifiers, но зато я могу, к примеру, точно выбрать формат вывода даты.
Доллар-нотация мне не нравится потому, что я к ней не привык, и потому, что я не понимаю как, к примеру, указать необходимость выводить два знака после запятой. Хотя объяснять ее, несомненно, проще.
Может, кто-нибудь из фанатов Nemerle покажет мне, как написать аналог вот этого:

Console.WriteLine("Rum-Coke: ${0:F2}", 10/3);
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[12]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 18:54
Оценка: :)
Здравствуйте, rameel, Вы писали:

I>>Я честно скажу — с трудом догоняю эти $. Я хорошо понимаю только то что легко проговаривать.


R>Подстановка переменных, сплайс-строка, интерполяция строки


Ну вот сравни

string.Format

статический метод Format класса String. Это ООП и потому легко. ООП — это уже каменый век. Такое знает почти каждый студент первого курса.

R>>>А почему не наоборот Причем, что первую что вторую тоже вполне может понадобиться разъяснять через printf, если человеку так легче.


I>>Потому что это будет обман будет.


R>В чем обман? Ну не знаком человек с шарпом, зато знает си, ну показал ты ему что


R>
string.Format("Output: {0}", a) = sprintf("Output: %s", a)


Это и есть обман. Слишком много деталей упускается из рассмотрения.
Re[12]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 19:12
Оценка: +1
Здравствуйте, rameel, Вы писали:

I>>Вот тебе и сложность.


R>

Интерполяция строки позволяет автоматически подставить вместо переменной ее фактическое значение. (с) Кто-то другой


R>Это ведь так сложно понять


Что значит автоматически и что значит фактическое значение ?

Вот, например, в Format все прозрачно — кучка перегруженых методов, указывается строка, значения и представление этих значений.

Единственная сложность — спецификаторы формата, их помнить не нужно, это справочная информация.

Т.е. string.Format("something:{0}",a) означает

у класса String вызывается статический метод Format которому передается строка и параметр а

вот это следует явно из записи, а терминология — ООП.

Если нужно больше информации, человек, который глянет в хелп, увидит, что строка может указывать представление согласно которому доп. параметры будут преобразованы в строки и вставлены в нужные места.

При этом все делается явно и абсолютно прозрачно.

Теперь сравниваем

http://msdn.microsoft.com/en-us/library/b1csw23d.aspx

и

Y>Все уже написано и не раз:
Y>1. String interpolation
Y>2. A little prize: string interpolation
Y>3. String interpolation i.e. $-notation

Y>Да и вообще, поиск рулит.

Re[12]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.12.08 19:14
Оценка: -1
Здравствуйте, IT, Вы писали:

IT>Думаю, что суть примера стала ясна всем с первого взгляда. В том числе и тебе. Но тебе же очень хочется поспорить, правда? Потролить чуток. Посамолюбоваться. Тут я бессилен.


Суть примера ясна, а вот возможности твоей первой строки не ясны даже Синклеру А в формате это ясно прямо из записи.
Re[8]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 20:18
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

VD>>Кто это придумал?

S>Это очевидно. Дело не в отсутствии исходников макроса, а в объеме работы. Сколько тебе потребовалось "допилить", чтобы Nemerle поддержал Linq?

Видимо ты забыл о чем шла речь. Напомню контекст:

V>>Но с другой стороны возможен компромиссный вариант, когда мы делаем незначительное изменение генератора (например, всего лишь добавляем вызов partial метода) и получаем тем самым возможность сделать ручное изменение, которое не пропадёт после повторной генерации исходников.
S>Речь о том, что это не всегда возможно.

Кто это придумал?


Я отвечу на твой вопрос сразу после того как ты скажешь какое он имеет отношение к данному обсуждению?

S>На всякий случай подчеркну, что речь о предположении prVovik о том, что для решения частной проблемы можно "просто добавить в макрос вызов partial method", а не о всеобщей применимости макросов.


Лучше, на всякий случай, поясни какое отношение имеет вопрос объем каких-то там работ к возможности подправить макрос и вставить в него те же partial-ы которые позволят вручную что-то там подправить.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 20:19
Оценка: :)
Здравствуйте, IT, Вы писали:

IT>Первый вариант тоже имеет право на жизнь и часто используется. У меня в конторе народ генерирует генератором Linq2SQL набор классов по БД, зачем вычищает оттуда весь мусор и уже далее поддерживает этот код вручную. В принципе, ничего плохого в этом нет. Небольшая автоматизации на начальном этапе.


Я бы за это руки отрывал. Намного проще создать качественный генератор.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 20:24
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

AVK>>Нет, надо перечитывать, пока не поймешь смысл написанного.


I>Как же он поймет если ты не хочешь прояснять и пояснять свою позицию ?


А, мне кажется, что это и есть позиция — отсутствие желания пояснять свои общие фразы. Ведь с общими фразами не поспоришь. А начнешь домысливать и тебя тот час уличат в мозговедстве или еще чем.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 21:05
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

R>>Да ну А обоснования будут?


I>А надо ?


Надо.

I>Не мог бы ты еще больше текста скипать ?


Там все равно кроме откровенной чуши ничего не было. Я было хотел возразить, но потом понял, что ничего не получится объяснить. Хочешь знать почему? Прочти вот это:
http://www.rsdn.ru/article/nemerle/Amplifier.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.


Парадокс Блаба

Что же в Lisp-е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.

И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.

Я начну с шокирующего утверждения: языки программирования отличаются друг от друга своей мощностью.

По крайней мере, мало кто будет спорить, что высокоуровневые языки мощнее машинного языка (машинный код и ассемблеры – VladD2). Большинство программистов согласятся, что, как правило, программировать стоит не на машинном языке, а на каком-нибудь языке высокого уровня, переводя программу в машинный код с помощью компилятора. Сейчас эта идея получила даже аппаратное воплощение — с восьмидесятых годов команды процессоров разрабатываются скорее для компиляторов, чем для программистов.

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

Все языки одинаково мощны, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.

Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций (VladD2: впрочем, бывает так, что средствами языка B в принципе можно решить проблему, но решение ее столь сложно, что решение это можно назвать чисто теоретическим).

Есть много исключений из этого правила. Если вы пишете программу, которая должна тесно взаимодействовать с программой, написанной на определенном языке, возможно, окажется разумным писать новую программу на том же языке.

Если вы пишете программу, которая должна делать что-то очень простое, вроде численной обработки больших массивов данных или манипуляций с битами, можно использовать язык не самого высокого уровня абстракции, тем более что программа будет слегка быстрее (VladD2: и то не факт).

Если вы пишете короткую программу, которую используете один раз и выбросите прочь, возможно, следует использовать тот язык, который имеет лучшие библиотечные функции для данной задачи.

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

Понятно, что уровень машинного языка очень низок. А высокоуровневые языки часто рассматриваются как одинаковые, по крайней мере, так принято считать. Но это не так. Технический термин "язык программирования высокого уровня" не обозначает ничего определенного. Не существует четкой границы между множеством "машинных" языков с одной стороны, и множеством "высокоуровневых" – с другой. Языки распределены в континууме (возможно, не просто континууме, а некой структуре, уменьшающейся кверху; важна здесь не форма, а сама идея о том, что существует, по крайней мере, частичный порядок) абстрактности, начиная от самых мощных "языков высокого уровня" вниз к "машинным языкам", которые, в свою очередь, тоже отличаются друг от друга по мощности.

Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python-у? (VladD2: учитывая свой опыт общения на форумах RSDN скажу, что, несомненно, станет ) Возможно, он ближе к машинному языку, чем Python.

А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl-хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык.

Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.

Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб.

Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык.

И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol-а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol-е ведь даже нет возможности X, присутствующей в Блабе!

Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе (VladD2: выделено мной).

Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. «Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!»

Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел в виду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.

Я понял это на собственном опыте, когда учился в старших классах школы и писал программы на Бейсике. Этот язык не поддерживал даже рекурсию. Трудно представить написание программ без рекурсии, но в то время мне это было не нужно. Я думал на Бейсике. Я был спец. Мастер всего, что изучил.

Пять языков, которые советует хакерам Эрик Реймонд, находятся в разных точках континуума мощности, и то, где они находятся относительно друг друга, — тонкий вопрос. Я скажу, что Lisp находится на вершине континуума. И чтобы поддержать это утверждение, я скажу о том, чего мне не хватает, когда я смотрю на остальные пять языков. Как же можно что-то сделать с ними, думаю я, без свойства Z? И самое большое Z — это макросы. (VladD2: Рассматривать макросы как отдельное свойство — это немного неправильно. На практике их польза увеличивается такими свойствами Lisp'а, как лексические замыкания и частичная параметризация (rest parameters) – аналогичная возможность в Nemerle назевается «частичное применение (partial application)).

Во многих языках есть что-то, называющееся макросом. Но макросы в Lisp'е уникальны (VladD2: на сегодня это так, только если глядеть на другие языки с высоты Lisp-а, но об этом позже). То, что делают макросы, имеет отношение, верите вы или нет, к скобкам. Создатели Lisp'а добавили все эти скобки в язык не для того, чтобы отличаться от других. Скобки в Lisp'е имеют особый смысл, они — внешнее свидетельство фундаментальной разницы между Lisp'ом и другими языками.

Программа на Lisp'е состоит из данных. И не в том тривиальном значении, что исходные файлы содержат символы, а строки — один из типов данных, поддерживаемых языком. После прочтения программы парсером Lisp-код состоит из готового к использованию дерева структур данных.

Дело не в том, что в Lisp'е странный синтаксис, скорее, его нет вообще. Программы пишутся в синтаксических деревьях, которые в других языках генерируются парсером во время разбора исходного текста. Эти синтаксические деревья в Lisp'е полностью доступны вашим программам, и вы можете писать программы, которые изменяют эти деревья. В Lisp'е подобные программы называются макросами. Это программы, которые пишут программы.

Программы, которые пишут программы? И когда же такое может понадобиться?

Не очень часто, если вы думаете на Cobol'е. И постоянно, если вы думаете на Lisp'е. Было бы удобно, если бы я дал пример мощного макроса и сказал бы: "Вот! Смотрите!". Но если бы я и привел пример, для того, кто не знает Lisp, он выглядел бы как белиберда. Рамки данной статьи не позволяют изложить все необходимое для понимания подобного примера. В книге Ansi Common Lisp я старался излагать материал как можно быстрее, но даже так я не добрался до макросов раньше страницы 160.

Однако мне кажется, что я могу дать убедительный аргумент. Исходный текст редактора Viaweb на 20-25 процентов состоял из макросов. Макросы сложнее писать, чем обычные функции Lisp'а, и считается дурным тоном использовать их там, где можно без них обойтись. Поэтому каждый макрос в той программе был необходим. Это значит, что примерно 20-25 процентов кода в программе делают то, что нельзя просто сделать на других языках.

Как бы скептически ни относился Блаб-программист к моим заявлениям о таинственной мощи Lisp'а, это должно его заинтересовать. Мы не писали этот код для своего собственного развлечения. Мы были маленькой компанией, и программировали так, как только могли, чтобы возвести технологический барьер между нами и нашими конкурентами.

Пытливый читатель может задаться вопросом, а нет ли здесь взаимосвязи? Некоторая большая часть кода делала нечто, что очень сложно сделать на других языках. Получившееся в результате программное обеспечение делало то, что программное обеспечение наших соперников делать не могло. Возможно, между этими фактами есть связь. Я советую вам подумать в этом направлении. Возможно, это все не просто старческие бредни.

http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 22:40
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>А я на полном серьезе считаю, что второй вариант очень сложный, но мощный. Я до сих пор путаюсь в format specifiers, но зато я могу, к примеру, точно выбрать формат вывода даты.

S>Доллар-нотация мне не нравится потому, что я к ней не привык, и потому, что я не понимаю как, к примеру, указать необходимость выводить два знака после запятой. Хотя объяснять ее, несомненно, проще.

Согласен. Скажу больше. У формат-стринга есть еще одно приемущество (в некоторых случаях) — она позволяет менять формат в рантайме.

S>Может, кто-нибудь из фанатов Nemerle покажет мне, как написать аналог вот этого:


S>
S>Console.WriteLine("Rum-Coke: ${0:F2}", 10/3);
S>


Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:
$"Rum-Coke: $(F2(10 / 3))"

Или тупо воспользоваться форматом.

ЗЫ

В этом споре замечательно продемонстрировано как самые прогрессивные идеи могут разбиваться о косность и упрямство недолеких людей заучивших однажды что-то и считающих дальше что это true way.

ЗЫЫ

Не надо называть тех кто выбрал Немерле фанатами. На фоне приверженцев остальных языков Немерлисты выглядят просто ангелами.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.12.08 23:46
Оценка: :)
Здравствуйте, IB, Вы писали:

VD>>Ага. И по этому на него лучше не равняться.

IB>Ты о чем? На данный момент это единственный внятный способ работать с LINQ2SQL, если лень хранимки писать.

Я о большинстве.

Массы делают свой выбор бездумно. Находясь в плохих условиях они с огромной веорятностью выбирают зло. Пример — Германия в двадцатых годах прошлого века.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 00:00
Оценка: +1
Здравствуйте, VoidEx, Вы писали:

VE>Какое предупреждение? Не могу представить. Вроде как без любого из $ (или даже обоих) всё нормально.

VE>Или предупреждение, что mayVar не используется?

Предупреждение будет, что в $-строке нет ни одного $-са. Если нужна просто строка, убери $ перед ней.
Данная проверка выявила 3 ошибки в компилятора (после ее добавления).

VE>Пример, кстати, неудачный, так как собственно фишки и не показывает. Ибо в аналогичном случае в C# всё будет так же:

VE>
VE>int mayVar = 1;
VE>WriteLine("Моя строка равна: {0}", myvar);
VE>


Это как пример напишешь:
int mayVar = 1;
WriteLine("Моя строка равна: {1}", mayVar);

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

VE>Я так понимаю, что отловит он ошибку количества аргументов. Это я придрался, конечно, к слишком общей фразе.


Это ты просто мало форматную строку использовал. В программах на дотнете бывают приколные баги. Вылетает исключение "бэд формат" и хрен его знает, что с ней делать, так как никакого объяснения о причинах исключения нет.

VE>Куда интереснее printf, но вот на Cayenne он выглядит на порядок проще.


Ну, так бросай свой любимый язык и пиши не нем. Потом расскажешь о том, что у тебя вышло.
Это я тебе к тому, что ты сравниваешь пример на совершенно академической подлке с реальным промышленным кодом.
В реальности обработка строк в виде списков — это кирдык проивзодительности. Макросы $ и аналоги не просто позволяют сложить строки, но еще и делают это максимально эффективно. Примитивная реализация тоже не заняла бы много места. В конце концов можно тупо повторить приведенный код на Немерле. Только это фикция и она кроме пенесометрии нигде бльше не пригодится.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Что меня не устраивает в МП в Nemerle
От: IT Россия linq2db.com
Дата: 29.12.08 00:03
Оценка: +1
Здравствуйте, VladD2, Вы писали:

IT>>За что? За то, что я написал следующий код не руками, а сгенерировал и уже больше никогда не испльзовал генератор?


VD>Так не бывает. Рано или поздно человек сталкивается с нуждой сгенерировать еще раз, но возможности уже нет.


Бывает, бывает. Есть генерилки, которые вообще не заточены на автоматическую генерацию вроде Custom Tools. С ними нужно повозиться, указать все необходимые параметры и потом раз и сгенерировать. После этого сгенерированный код используется как обычный рукописный. Народ этим широко пользуется.

IT>>А проблему, которую пораждает такой подход ты можешь назвать?


VD>Изменение модели.


Какой модели?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 00:23
Оценка: -1
Здравствуйте, VoidEx, Вы писали:

VE>Я согласен, Хаскель тут был просто в качестве примера некоего другого языка, тоже требующего levelup. Но со стороны Блабиста Nemerle не имеет преимуществ, а потому чего туда лезть?


С точки зрения Блаба (отличныйе примеры Блабов в этой теме дискутируют) все языки равны по своим возможностям. Просто некоторые имеют непонятные феньки которые все запутывают (с их точки зрения).

102-ой раз повторяю — Немерле выглядит для блаба как его любимый Блад. Он может писать на Блабе и потихонечку изучать базис который позволит в итоге оценить мощность изучаемого языка. В итоге, он незаметно для себя, перестает быть блабом и его кругозор увеличивается.

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

В 2006-ом я тут один сражался. Меня поддерживал один, ну, от силы два человека, а остальные только посмеивались. Сейчас на форуме уже масса народа которые говорят то что говорил и продолжаю говорить я. Тот же IT начал со смешков в мою сторону, но попробовав втянулся и в итоге понял, что есть языки совершеннее чем C# и С++ которые он знал.
Блабы могут называть этих людей (и меня, естествнно) фанатами. Но это не так. Фанаты — это те кто тупо лабает на Блабе и с пеной у рта доказывает, что их Блаб — это верх совершенства.

VE> Поэтому он не пойдёт туда просто так, а фичей он не поймёт из-за того, что Блабист. Так что ему сначала придётся понять фичи (или хотя бы понять, что они существенны, что в принципе почти равносильно), а уже потом он может принять такое решение и доучиваться.

VE>А фраза моя была ответом на фразу "Проблемы парадокса Блаба для Nemerle нет" (пишу по памяти). А она есть.

Проблема есть. И никто не утверждал обратного. Ты просто не верно понял. Утверждалось совсем иное. Если под абстрактным именем Блаб скрывается C# (или на худой конец С++ или Ява), то блабу будет проще сделать первые шаги, и будет возможно продвигаться в расширении своего кругозора постепенно и безболезненно.

Вот недавно один из наших форумчан решил изучить Немерле. Интересно, что основной проблемой для него стали не какие-то там заумности ФП, а банальная рекурсия. От нее многим крышу рвет. А как раз Map, Fold и Filter он освоил на раз. Макросы тоже оказались не самым простым орешком, но прошли намного проще по сравнению с банальной рекурсией. Вот такие наблюдения из жизни. А вы говорите блабы...
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Что меня не устраивает в МП в Nemerle
От: VoidEx  
Дата: 29.12.08 01:42
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Лучше поупражняйся сам и опиши чем лучше делать наоборот. Все что ты выкинишь из своих доказательств и будет ответом на твои слова.


Нет нет. "Наоборот" — это уже будет не доказательство. За что люблю детские вопросы типа "зачем", "почему", потому что они раскрывают, что тот, кто говорит, сам ничего не понимает, если до сути докопаться.
Вот ты уверен, что лучше. Абсолютно уверен. Но не знаешь, почему. Для такого казалось бы очевидного утверждения нужно доказать, что хорошие спецы с новой технологией в целом обойдутся дешевле тысячи блабов. А в жизни куча примеров и первого, и второго.
Re[8]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.12.08 09:20
Оценка: +1
Здравствуйте, Undying, Вы писали:
U>Можно вопрос? В своих приложениях string.Format("Некая константа: {0}", obj) я пишу по большим праздникам, зато очень часто пишу TraceHlp2.AddMessage("Некая константа: {0}", obj). Можно объяснить как сплайс-строка позволит мне записать TraceHlp2.AddMessage лучшим образом?
Очевидно, тебе достаточно заменить все аргументы AddMessage одним вхождением сплайс-строки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[9]: Что меня не устраивает в МП в Nemerle
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 29.12.08 11:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>>>Это просто не реализовано. Если действительно надо, то можно вызвать функцию форматирования:

VD>>>
VD>>>$"Rum-Coke: $(F2(10 / 3))"
VD>>>

S>>А знак доллара выведется? Или он должен быть частью функции форматирования?

VD>Вот это:

VD>$(F2(10 / 3))
VD>сплайс. Все что заключено в скобки — это выражения. F2 — это простая функция (гипотетическая, ее реально нет).
Это я понимаю. Просто мне кажется несколько избыточным требовать на каждый чих писать отдельную функцию. Это с точностью до наоборот противоречит идее сделать запись более компактной.
Кроме того, такая функция затрудняет понимание. Стандартные форматные строки входят в курс молодого бойца, и мы имеем права требовать их понимания от любого стажера. А вот все эти F2; FX и прочие нужно пойти и разобрать по исходнику, потому что документации на них нет, а имена — коротки до нечитаемости.

VD>Скорее как аналог PHP или Руби. Пояснять мне не с руки, так как не я это дело придумал. Но предположить могу.

VD>С одной стороны в языке уже есть $-нотация квази-цитирования применяемая для композиции и декомпозиции кода в макросах. Это делает такой подход вполне естественным.
VD>Это практически синтаксис Руби и новой версии Питоне (если не ошибаюсь). Разницы почти никакой. Только синтаксические различия. Можно сделать и такой макрос.
VD>Что же касается МСДН-а, то сколько я не работал с дотнетом все время для меня было проблемой найти описание формата. Он не интуитивен и при этом очень плохо ищется в МСДН. Так что не думаю, что это реально стало бы приемуществом.
Во-первых, теперь это починили. Ссылка на документацию по формату лежит прямо на странице string.Format.
Во-вторых, зацени: это не твоя проблема. Парни из майкрософт ежегодно вкладывают тучу денег в поддержание вот этой документации. Литературы по шарпу — море разливанное. Если бы ты сдавал экзамен на MCSD по нему (как это делают все индусы), то у тебя бы было 90% знание этих форматов и знание, где именно в MSDN они лежат.
VD>Мы думали о введении формата через двоеточие. Но до реализации руки так и не дошли. Ну, и потребности на практике особой нет.
Тут вопрос открытый — пока что user base очень мала; рассчитывать на то, что все хорошие фичи будут запрошены пользователями пока смело. Нет практики — нет потребности; нет потребности — нет реализации; нет реализации — нет практики. Ты же вот сам пишешь "ну или использовать тупой Format". Возможно, это underestimated feature, которая всем была бы мегаполезна, будь реализована в полном виде.
(Дисклаймер: может быть, и не была бы. Я не имею права выступать за всё сообщество.)

VD>Случаи бывают разные. Кроме того $-нотация поддерживает и работу со списками.

Прикольно, что ни в одной ссылке, приведенной про нее, это не написано. Или приводимые тобой примеры — частный случай выражений?

VD>Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.

Ну, с учетом того, что у меня всегда в загашнике лежит функция string Join(this IEnumerable<T> source, string separator, Function<T, string> converter), всё не так страшно, как ты описываешь
Это сведется собственно к
WriteLine("Function {0} {1}({2})", attributes.Join(" "), parameters.Join(", ", Parameter p => string.Format("{0} as {1}", p.n, p.t)));

не слишком много оверхеда по сравнению с
WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>);

Но ты, конечно же, прав. Твой вариант компактнее и нет риска ошибиться с номером аргумента.

Хотя на самом деле — фишка в том, что разработчики дотнетного форматирования уже проделали большую предварительную работу.
И где-то я встречал статью про user-defined format strings, которые позволяют вообще отжигать не-подетски. Если то, что я смутно помню — правда, то можно было бы замутить реализацию приведенного тобой конвертера списков в строку на основе всё той же format string технологии, без хардкода.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[10]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 11:59
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

VD>>Попробуй переписать его на string.Format и сразу станет очевидно, что это совсем неудобно.

S>Ну, с учетом того, что у меня всегда в загашнике лежит функция string Join(this IEnumerable<T> source, string separator, Function<T, string> converter), всё не так страшно, как ты описываешь
S>Это сведется собственно к
S>
S>WriteLine("Function {0} {1}({2})", attributes.Join(" "), parameters.Join(", ", Parameter p => string.Format("{0} as {1}", p.n, p.t)));
S>

S>не слишком много оверхеда по сравнению с
S>
S>WriteLine($<# Function ..$(attributs; " ") $methodName(..$(parameters; ", "; (n, t) => $"$n as $t")) as $retType #>); 
S>


Гы. Ты уже допустил ошибку. Имя метода ты пропустил . А ты еще додумался сделать высокоуровневый Join. Большинство выходцев из серых масс вообще бы цикл залудило и стало бы использовать StringBuilder.

S>Но ты, конечно же, прав. Твой вариант компактнее и нет риска ошибиться с номером аргумента.


Заметь еще что:
1. В нем проще разобраться так как не надо выискивать соответствие плэйсхолдеров параметрам. Уже в таком простом примере я лично путаюсь. А что будет в более сложном?
2. Я пользовался исключительно стандартными для языка средствами (макрос входит в стандартную библиотеку, а твоя функция — нет).
3. Я использую декларативное описание паттерна "печать списка", а ты вынужден приводить ее реализацию.
4. В результате выполнения моего кода получится максимально эффективный код. Причем тебе не придется об этот заботиться.

Не так мало, для простого примера. Согласен?

S>Хотя на самом деле — фишка в том, что разработчики дотнетного форматирования уже проделали большую предварительную работу.

S>И где-то я встречал статью про user-defined format strings, которые позволяют вообще отжигать не-подетски. Если то, что я смутно помню — правда, то можно было бы замутить реализацию приведенного тобой конвертера списков в строку на основе всё той же format string технологии, без хардкода.

Мне всегда больше нравилось слово "есть", чем слова "можно было бы".

Кайф макроса в том, что в отличии от хардкода его можно менять как обычную функцию. Так что если ты мне покажешь решение более элегантное, то я его всегда смогу реализовать.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 13:25
Оценка: -1
Надоел. Тебе явно хочется по упражняться в разговорном жанре.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.08 15:17
Оценка: +1
Здравствуйте, Undying, Вы писали:

U>Плюсы:

U>1) Некоторые ошибки форматирования станут невозможными, например, string.Format("Некая константа: {0}, {2}", obj1, obj2).
U>2) Более очевидный порядок переменных в строке.

Главное, что такие строки намного лучше читаются, так как сами спалайся говорят о своем содержимом.

U>Минусы:

U>1) Добавление в язык птичьей конструкции "$", которая не вызывает никаких ассоциаций, соответственно плохо запоминается.

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

Ты без проблем сам запомнил все что нужно и процитировал прямо. Что тут еще запоминать?
К тому же в языке $ уже используется для квази-цитат. И совершенно логично, что сплайсы в строках которые почти аналогичны по смыслу сплайсам в квази-цитировании, выглядят точно так же.

U>2) Ошибок форматирования, пожалуй, станет меньше, но они не исчезнут, такое ни компилятор, ни рантайм не отловят: $"Некая константа: obj1, $obj2" // забыли спецсимвол перед obj1.


Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?

U>3) Сложный вывод форматированных значений.


Тут это уже обсуждалось. Его не так много на практике и данный макрос не так сложно расширить поддержкой форматирования. Просто так как это может быть сделано функцией, и так как это пока что никому особо не надо, никто это не делает.

U>Также еще несколько вопросов:

U>1) Что будет если переданное макросу сплайс-строки значение равно null?

Будет выведена пустая строка. Это собственно поведение string.Concat() в вызовы которых перепивается в код строки.

U>2) Как записать такую форматную строку: string.Format("{0}добавление")? Т.е. как макрос понимает, что имя переменной закончилось и началась строковая константа?

"$(x)добавление"

В скобках могут быть любые вычисления, а не только ссылки на переменные.

U>3) Как работает приведенное Владом: $"Rum-Coke: $(F2(10 / 3))"? В какой код эту запись развернет компилятор?

Что-то вроде:
string.Concat("Rum-Coke: ", F2(10 / 3))

Что аналогично коду такому коду на Шарпе:
"Rum-Coke: " + F2(10 / 3)

Причем надо понимать, что макрос можно и переписать если на то появятся основание. Это не хардкод в компиляторе.

U>В принципе если сравнивать приведенные плюсы и минусы, то возможно плюсы и перевесят, хотя и несильно. Но проблема в том, что записи: TraceHlp2.AddMessage("Некая константа: {0}, {1}", obj1, obj2) и TraceHlp2.AddMessage($"Некая константа: $obj1, $obj2") неэквивалентны. Например, завтра мне понадобится лог локализовать. Что мне делать если я использую строку форматирования понятно — исходная строка форматирования становится ключом, по которому находится строка форматирования для нужного языка. А что я должен делать, если использовал сплайс-строки?


Например, использовать аналогичный макрос по имени "L" (вместо "$") который поддерживает атоматическую локализацию.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Что меня не устраивает в МП в Nemerle
От: Lloyd Россия  
Дата: 29.12.08 18:38
Оценка: +1
Здравствуйте, IT, Вы писали:

L>>А ты поднимись повыше и посмотри вопрос. Если лень, то вопрос был о том, как сделать, а не делать или нет.


IT>Видишь ли в чём дело. Если бы ты ответил на вопрос зачем, то стало бы понятней, что тебе нужно на самом деле.


Странно, я считал, что само понятие "локализация" достаточно самоочевидное.
Простой пример — консольное приложение, пишет что-либо на консоль.
Re[11]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.12.08 04:12
Оценка: :)
Здравствуйте, Lloyd, Вы писали:

VD>>Все что нужно сделать — это заменить "$" на "L". Далее при компиляции автоматически создается файл куда "выкидываются" все строковые литералы где вместо сплайсов стоят некие заменители вроде любимых тобою "{0}".


L>Как это будет работать с source control-ом?


А в чем проблема то? Ты бы вообще, включал бы воображение и тогда не нужно было бы отвечать на столько вопросов.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Что меня не устраивает в МП в Nemerle
От: Don Reba Канада https://stackoverflow.com/users/49329/don-reba
Дата: 30.12.08 14:55
Оценка: +1
Здравствуйте, q__q, Вы писали:

__>И все-таки, если не сложно, можешь прояснить этот вопрос?

__>TFS, например, ставит readonly на файлы, взятые из репозитория. Если при компиляции создаются/меняются файлы, то получается компилятор должен знать, что делать с такими файлами, должен знать о том, что недостаточно снять атрибут readonly, нужно еще и зачекаутить файл в TFS-е.
__>Неужели макрос для L-строк делает и это? А как быть, если используется какая-то другая VCS? Непонятно.

Очевидно, файлы создающиеся в процессе компиляции в репозиторий не кладут, следовательно макрос к VCS никакого отношения не имеет.
Ce n'est que pour vous dire ce que je vous dis.
Re[12]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.12.08 21:33
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Это от того, что единственное, что вы пишете — это компилятор. У вас там наверное во всём проекте ни одного дабла, кроме как в тесткейзах, нет.


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

А я как-то давно заметил, что код который пишется из соображений "Вдруг спросят, а у нас нет Зингельшухера..." ни когда не бывает удобным и часто-употребимым. Меж тем есть тонна задач которые реально ждут решения.

К тому же формат String.Format-а меня не вдохновляет. Вот если найдется красивое решение, то можно будет его реализовать. Пока что мне ничего умного в голову не приходит.

Для Nemerle.StringTemplate я использую простой подход основанный на том, что в шаблоне можно перегрузить метод ToString в котором реализовать подходящее форматирование для нужного типа. Это удобно и интуитивно понятно. Вот если удастся придумать нечто подобное для обычных сплайс-строк, то я его обязательно добавлю.

S>А в жизни ни даты, ни даблы никто никогда не выводит в "дефолтном" формате. Слишком велик разброс вариантов. Задавать же, к примеру, количество знаков после запятой, через культуру — еще менее удобно, чем подставлять ad-hoc функцию. В культуре есть понятие стандартного вывода денежных значений. Но никакого типа currency нет, а сплайс-строки не предоставляют возможности использовать эту настройку. В String.Format я пишу {0:C} и всё — будет выводиться корректный префикс и количество цифр после точки.


Да, да. В теории теория и практика одинаковы. На практике — нет.

В общем, ты увлекся тем, чем тут очень любят увлекаться — выискиванием фатальных недостатков.

Кто тебе сказал, что сплайс-строки — это какая-то там киллер-фича? Это просто удобно. Чертовски удобно! Но не более того. Это не замена String.Format на все случае жизни. Такой задачи и не ставилось. Просто люди сделали для себя простенькую макру которая со временем равилась в весьма удобное решение. Кайф Немерле не в том, что в нем есть сплайс-строки, а втом, что каждый может создать в не нечто удобное для себя и окружающих. Причем сделать это так как хочется, а не так как это заставляют сделать проклятые обстоятельства в форме компилятора, язка и т.п.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Что меня не устраивает в МП в Nemerle
От: VladD2 Российская Империя www.nemerle.org
Дата: 31.12.08 07:00
Оценка: +1
Здравствуйте, Undying, Вы писали:

U>В чем достоинство именования вроде string.Format?


А оно есть?

U>В том, что если я завтра захочу написать аналогичную функцию мне понятно как ее назвать (<тип объекта>.<действие>), оставаясь в рамках концепции предложенной разработчиками шарпа.


Да, да. Почти стройная теория если не вспоминать о наличии разных: Write, WriteLine, AddMeaasge и т.п.

U> Если же я завтра захочу написать свой макрос аналогичный $ как мне его назвать? $my, $$, L, $my_macros, my, my_macros?


Довольно бессмысленно решать проблему которой нет. Не правда ли?

Если тебя трогает только название, то открою тебе большой сикрет. Макрос называется sprint, а $ — это его синоним.
VD>>Другими словами мы нашли недостаток в том, что ошибок станет меньше, а не ноль?

U>Вот при такой записи допустить ошибку необнаруживаемую компилятором практически невозможно:


U>"Некая константа: " + _.s(obj1) + ", " + _.s(obj2);


Такая запись полностью не читаема. А ошибки, как не странно, возможны. Никто не помешает поместить имя переменной внутрь строки. Если ты укажешь на подсветку, то не боись. Для сплайс-строк она тоже есть и прекрасно видно где находится имя переменной.

U>ps

U>Вообще, если бы сплайс-строка выглядела примерно так:

U>string.Inline("Некая константа: {obj1:F2}, {obj2}");


Это весьма не трудно реализовать на макросах. Проблема тольк в том, что в отличии от знака $ фигурные скобки довольно часто используемые символы и их удвоение сильно портило бы внешний вид строк.

Бесполезная же гора букв "string.Inline" только теоретикам кажется хорошим решением. По жизни от строк хочется чтобы они занимали минимум места и создавали минимум шума.

U>То решение бы мне наверное даже понравилось, т.к. оставалось бы в рамках концепции шарпа.


Ну, что же бери и делай. Все в твоих руках. Я даже готов тебе помочь советами. А там поглядим будет ли кто-то пользоваться твоей версией.

ЗЫ

Читая рассуждения о Немерле мне вспоминается реклама майонеза:
— (девочка) Все говорят, что майонез Скит вкусный, а я не верю.
— А Вы его есть пробовали?
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что меня не устраивает в МП в Nemerle
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.12.08 21:03
Оценка: -1
Здравствуйте, alvas, Вы писали:

A>>>Nemerle создает стандартные .Net сборки. Так что достаточно посадить одного инструментальщика.


I>>Я это всё понимаю, теоретически тип-топ.


A>А практически?


А практически один специалист по немерле погоды не изменит и всем придется учить все мыслимые и немыслимые тонкости и нюансы, которые всегда есть во всех технологиях.

В итоге получается так — тот, кто имеет базу на низкоуровневых языках-инструментах, например WINAPI или COM, никогда не поймет того, кто пишет на высокоуровневом инструменте без этой базы.

И даже без этого всегда начинаются проблемы с набором людей.

и если на проекте взять и внедрить МП Немерле, то специалистов брать будет просто неоткуда, а если и найдутся, то еще n-месяцев готовить.
Re[13]: Что меня не устраивает в МП в Nemerle
От: 4058  
Дата: 04.01.09 12:37
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Посему стоит брать не сильных людей, а тех, кто задержится подольше.

I>>>Разумеется, берётся человек, который минимально может справляться. При этом его уровень отстаёт от желаемого заметно.

G>>Ну вот вы сами описали ваши проблемы. Получается не существует "вселенской тупизны кодеров", вы сами её локально у себя создаете.


I>Ага, на рынок труда берем так и влияем.


Получается, что влияете, т.к. открываете вакансии для "минимально справляющихся".
На мой взгляд лучше иметь дело с 5-тью специалистами, чем с 100-тней оболтусов.
Это банально дешевле + высокая гарантия положительного результата.
Я это говорю на основании горького опыта участия в одном крупном проекте,
когда получалось, что 5% вытягивают остальные 95%.
С таким подходом проект или просто закрывается (банкрот), или тянется мучительно
(как для заказчика, так и для исполнителя) долго.

Здесь дело не столько в текущем уровне знаний, сколько в потенциальных возможностях.
Вот допустим человека без музыкального слуха, можно научить играть почти на любом муз. инструменте.
(обучаемый под воздействием частых повторений запомнит в какой момент времени куда надо нажимать/дуть/стучать и т.п.)
Но этот процесс будет сложным, дорогим и главное неприятным для окружающих, а конечный результат будет слабоват.
Тогда напрашивается филосовский вопрос, а зачем же оно надо?
Re[6]: Что меня не устраивает в МП в Nemerle
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.01.09 00:17
Оценка: +1
I>Спрос изменился, надо пересмотреть требования и, обычное дело, здесь вполне возникает ситуация когда код делает не совсем то, для чего создавался.
I>И тут решение одной проблемы всегда влияет на решение другой.

У нас это называется говнокод.
Изменения требований не должны ломать архитектуру системы, если таковая есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[21]: Что меня не устраивает в МП в Nemerle
От: minorlogic Украина  
Дата: 07.01.09 13:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Ты не думал, почему в России московские и питерские ЗП, считай, только в Москве и Питере ?


I>>>Неужели вся Россия из дураков, которые не понимают, что можно взять и всем дать московские ЗП что бы кругом были мега-специалисты ?


M>>Просвяти пожалуйста, я логики не вижу в упор.


I>Логика простая — не ты один можешь ЗП задирать вверх.

Логично, это рынок.

I>Ну дадим мы топу московскую ЗП, что с того ? На стартапе где понадобится такой же специалист, ему все равно дадут больше.


Мы все умрем, зачем дышать?

Конечно же риск что ктонить уйдет всегда существует . Но выравнивая зарплаты с легко достижимыми регионами мы снижаем до нуля риск что специалист уйдет изза денег.
Причем себистоимость (содержание офиса и т.п.) в регионе ниже чем в москве.

I>А в москве на стартапе еще больше. А в ньюйорке на стартапе еще больше.

Еще раз повторюсь , риск ухода изза зарплаты снизится значительно.

I>Периодически появляются фирмы, которые задирают ЗП что бы переманить топов к себе.

Хорошо, вы меня убедили с таким подходом к бизнесу лучше закрывайтесь. Зачем вообще что то делать ?

I>Это работает разово, что бы на первое время набрать топов,а потом все такие фирмы в течении года сравниваются по ЗП с остальными.

Замечательно! конкуренция с Москвой это отлично, у вас при одинаковых зарплатах лучшие условия чем в Москве, т.о. можно сманить из москвы топовых специалистов. Что вас пугает ?

I>Исключений не было ни разу.

Ээээ.... вероятно вы что то делаете не правильно , повторюсь что есть успешные примеры.

I>Есть один способ — полностью забить на налоги и пересесть в подвалы или коттеджи хрен знает где, тогда можно потянуть московские ЗП.

Это уже ваши внутренние дела.

I>Но эт уже за счет рисков или за счет ухудшения условий труда.

см выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[25]: Что меня не устраивает в МП в Nemerle
От: minorlogic Украина  
Дата: 07.01.09 15:30
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


M>>Соврал , если отталкиваться от средних то там в 1.5 раза выше


I>Т.е. в полтора раза выше средней и это уже московская ?


I>У нас примерно на 30-50% выше средней и это и близко не московские.


I>Про что я тебе и говорю.


Это совершенно не меняет моих предпосылок, а скорее наоборот , есть БООльшой запас.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[21]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.01.09 18:17
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


G>>>>Почему вынуждены?

I>>>Потому что рынок местный так устроен.
G>>рынок состоит из его участников.
I>Разумеется, только кроме работодателей есть еще и работники и ты их почему то отказываешься рассматривать.
Предложение на рынке рабочей силы разработчиков образуется в основном за счет вчерашних (а может и нынешних) студентов, как вы сами пишете. Уровень большенства из них примерно одинаковый, потенциал никто увидеть не может, даже сами работники.
Если вы есть спрос на высококвалифицированных специалистов, то эти вчерашние студенты стремятся стать высококвалифицированными и получит нормальную работу (за дормальные деньги). Если такого спроса нет, то хорошие спецы будут валить в Москву.
Создавая спрос на быдлокодеров (утрировано) вы тем самым уменьшаете спрос на топов.

I>>>Чуть ниже среднего, про что тебе и говорю — на рынок влияния почти не оказываем. Но по любому оказывается так, что мега-стратегией пользуются все подряд.

G>>Оказываете, даже больше чем на 1%.
I>За счет чего больше 1% ?
За счет того что множество мелких фирм, выставляющих вакансии, оказывают менее согласованное влияние на рынок.

I>>>Уезжают не только в москву, но и еще на более денежные места.

G>>Это какие?
I>Ньюйорк, Лондон
Прямо каждый второй уезжает?

I>>>Только пока найдется менеджер для комманды топов, пока наберет комманду топов, пока они въедут в проект, пока в предметную область, притрутся друг к другу, глядишь и деньги ушли впустую.

G>>Улыбнуло. Еще раз повторюсь: ставка на качество всегда окупается в долгосрочной песпективе.
I>Я знаю, много контор с этого начало. И мало кто смог продолжать.
И почему не смогли продолжать?

G>>>>Надо проанализировать причины по которым уходят. У нас такой картины не наблюдается.

I>>>В том то и дело, что сначала надо анализировать, а уже потом советовать.
G>>Так анализируйте. Вы же называете факты, а не причины. А потом по этим фактам делаете выводы о "вселенской тупизне кодеров".
I>Выводы о контингенте на рынке труда я делаю по результам собеседований.
Студенты везде одинаковые. Но большенство софта не студентами пишется.

I>Скажи честно, сколько раз ты видел людей на собеседовании, которые длину строки определяют через sizeof ?

Слава богу собеседовал только людей на .NET.

I>>>Ну это почти тоже самое. Будь такое возможно, много фирм взяли бы и сделали.

G>>Значит есть другие причины.
I>Причин вагоны, это называется рынок.
"Рынок" — это не какая-то злая сила. У рынка определенные есть законы, крупные игроки вполне могут влиять на рынок.

I>>>Мы специально не набираем низкоквалифицированых. Наоборот, отсеивается очень много людей, до 90% про которые я и говорю.

G>>Так а вы по какому принципу отсеиваете?
I>По простому — интерес и набор знаний-умений.
Так вы же писали что берете тех кто подольше задержится.

I>>>Если топ говорит, что будет работать год, это значит, что интереса к нашей работе у него нет и он здесь не нужен.

G>>Значит у вас работа неинтересная?
I>Работа простая — делаем софтверные продукты под заказ и на продажу.
Под это определение 99% проектов подходит.

I>>>Полгода человек обычно вникает в проект, до года — в предметную область.

G>>Этот бред слышал сотню раз. Для нормального спеца вникание в проект — месяц-два, в предметную область, если совершенно новая для него — максимум полгода.
I>Ты хочешь сказать, что спец вникнет в проект за два месяца, без разницы от объемов кода и объемов функционала ?
Разница от объема кода будет, то время вникания от объемов зависит логарифмически.

I>Не иначе, супермен какой то этот нормальный спец.

Да нет, как раз нормальный спец.

I>>>Проще. Конторы так и делают — переводят самые критические проекты в Москву, если там есть офис.

G>>Я работал в конторе с московсим начальством. Там начальство вполе спокойно считало что программисту можно платить ЗП в 3 раза ниже московского уровня. Ситуация там почти как вы описываете.
I>Ситуацию ты вряд ли представляешь, т.к. вместо прояснения сразу начал советовать.
Нету разницы, "формулы успеха" давно придуманы. Вопрос только в том почему вы им не следуете.

G>>Так у вас платят ЗП в треть московской? Понятно почему уезжают.

I>У нас платят выше чем средняя по городу на 30-50% и тем не менее до Москвы далеко.
Насколько далеко? В два или в три раза отличие, или в полтора?
Конечно из-за такой разницы поедут в Москву, я бы поехал.

G>>А причина вашего неуезда на более денежное место называется "лень".

I>Я как то не вижу ни одного преимущества, кроме денежного, что бы ехать в Москву. И это для меня не самое главное.
А что главное?
Re[23]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.01.09 23:19
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>если считать что столько же работает и на третьем курсе и на четвертом и сразу после окончания(мешает распределение), то стало бть студентов около 1000 человек всего. Примерно 10% от рынка.

При 10000 человек в разработке ПО всего участинками рынка рабочей силы в один момент являются далеко не все. И большую часть составляют именно вчерашние студенты.

>>Уровень большенства из них примерно одинаковый, потенциал никто увидеть не может, даже сами работники.

G>>Если вы есть спрос на высококвалифицированных специалистов, то эти вчерашние студенты стремятся стать высококвалифицированными и получит нормальную работу (за дормальные деньги). Если такого спроса нет, то хорошие спецы будут валить в Москву.
G>>Создавая спрос на быдлокодеров (утрировано) вы тем самым уменьшаете спрос на топов.

I>Это очень грубая модель. Мы вот быдлокодеров точно не берем

Ну если берете "минимально справляющихся", то это так и есть.

G>>>>Это какие?

I>>>Ньюйорк, Лондон
G>>Прямо каждый второй уезжает?

I>Нет конечно. Но есть еще и стартапы, некоторые свои фирмы открывают или уходят фрилансить. Вот суммарно получится примерно каждый второй.

Хороший показтель того что программистам мало платят, причем не в вашей конторе, а вообще в регионе.

G>>>>Улыбнуло. Еще раз повторюсь: ставка на качество всегда окупается в долгосрочной песпективе.

I>>>Я знаю, много контор с этого начало. И мало кто смог продолжать.
G>>И почему не смогли продолжать?
I>Потому что для команды топов нужен топ-менеджер
Так наймите такого менеджера. Он любых денег стоит в любом регионе.

I>>>Выводы о контингенте на рынке труда я делаю по результам собеседований.

G>>Студенты везде одинаковые. Но большенство софта не студентами пишется.
I>Пишется, в том то и дело.
Ну это у вас так.
В мировом масштабе большая часть софта написана индусами.

I>Ну раз дотнет, тогда так

I>Человек не в курсе про вирт. методы, индексеры, делегаты и обработку исключений.
I>Т.е. он даже C# 1.0 не смог осилить.
I>Вот таких часто видишь ?
Не-а. Аура сложности C# и .NET спасает от людей, которые не удосужились одну книжку прочитать. Да и брали мы не абы-кого.

I>Но как правило, есть определенные слои — студенты например остаются надолго.

Странно, почему так получается. По моим наблюдениям именно наиболее грамотные студенты очень быстро "растут" и их аппетиты меняются не соизмеримо с щедростью начальства.

I>>>Работа простая — делаем софтверные продукты под заказ и на продажу.

G>>Под это определение 99% проектов подходит.

I>Есть определенная специфика отрасли, в основном наукоемкие десктоп-приложения, проектам в среднем лет по 5. Они не заканчиваются, разрабатываются версия за версией пока есть спрос.

Такой тип проектов я называю "болото". Самый непревлекательный тип проектов для опытных разработчиков.
Большенство задач сводятся к саппорту существующего кода, никаких инноваций и новых технологий на таких проектах не встретишь.
Для такой работы студенты как раз подходят

I>>>Ты хочешь сказать, что спец вникнет в проект за два месяца, без разницы от объемов кода и объемов функционала ?

G>>Разница от объема кода будет, то время вникания от объемов зависит логарифмически.
I>Все равно в два месяца не верю.
Еще сильно зависит от языка и архитектуры. Я работал на проекте, архитектуру которого ведущий разработчик объяснил за 20 минут. В дизайн подсистемы, с которой мне предстояло работать, я вник за пару дней с помощью более опытных товарищей. Была куча полезных диаграмм, coding-styles были соблюдены во всем проекте, использовались известные паттерны (я о них потом узнал), хотя иногда и не к месту, а самое главное была предусмотрена процедура ввода новчиков в курс дела.
Всего проект состоял из примерно из миллиона строк кода.
Реальный код я нчал писать через месяц.

Так что пара месяцев — вполне реально.


G>>>>Так у вас платят ЗП в треть московской? Понятно почему уезжают.

I>>>У нас платят выше чем средняя по городу на 30-50% и тем не менее до Москвы далеко.
G>>Насколько далеко? В два или в три раза отличие, или в полтора?
G>>Конечно из-за такой разницы поедут в Москву, я бы поехал.
I>dev.by — вот там смотри.
Хм... Зашел в статистику по ЗП, С++ средняя зп 1100$, вы платите выше на 30%-50%, те 1400$-1600$ грубо говоря. И это для не самых крутых разработчиков.
Топу вполне можно платить в 2 раза больше, потому что он реально будет работать за двоих, то есть 2800$-3200$. Получаются очень даже московские ЗП для топов.
Или что-то не так?
Re[12]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 07.01.09 23:21
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Архитектура и меняется рефакторингом, а у же потом вносится новый функционал. Но часто отделить рефакторинг от написания нового функционала просто невозможно.

Значит вы неправильно делаете рефакторинг.
Re[23]: Что меня не устраивает в МП в Nemerle
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.01.09 02:05
Оценка: +1
M>>Замечательно! конкуренция с Москвой это отлично, у вас при одинаковых зарплатах лучшие условия чем в Москве, т.о. можно сманить из москвы топовых специалистов. Что вас пугает ?
I>Из Москвы сюда никто не едет. Уровень жизни в округе совсем не московский.

У тебя кажется довольно идеалистичные представления о московской жизни. По мне, так тут конкретная клоака. Здесь уровень бизнеса высокий, а уровень жизни — как придётся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[14]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.01.09 13:00
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


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


I>>>Архитектура и меняется рефакторингом, а у же потом вносится новый функционал. Но часто отделить рефакторинг от написания нового функционала просто невозможно.

G>>Значит вы неправильно делаете рефакторинг.

I>Просто ты постоянно пытаешься чего то додумать, вместо того, что бы спросить.

Если вы думаете что невозможно отделить рефакторинг от написания нового функционала, то вы неправильно делаете рефакторинг.
Re[29]: Что меня не устраивает в МП в Nemerle
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.01.09 16:12
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


I>>>Это ты за себя говори. Я лично сомневаюсь, что любую область можно за год освоить. Сколько ни работаешь, а постоянно чтото новое узнаёшь.

G>>Ну продолжай сомневаться.

I>"знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет"

I>Ты уж определись, год или десять лет.
Еще раз. Для вхождения в проект на уровне написания production кода для задачи сформулированной технически нормальному программисту хватает в среднем пары месяцев. Для вхождения в проект на уровне написания production кода для задачи сформулированной в терминах предметной области нормальному программисту надо полгода-год, в зависимости от проекта и предметной области.
Если надо обладать знаниями чтобы написать проект с нуля, когда есть только общая формулировка задач в терминах предметной области, то такой уровень может быть не достигут и за 10 лет.


G>>>>Так это вообще другая величина. Такое "везжание" требует получения знаний на уровне автора проекта, что может быть не достигнуто и за 10 лет.

I>>>О чем и речь. То въезжание, о котором ты говоришь, и за въезжание не считается.
G>>Это ты так думаешь. Я работал с десятками людей, которые успешно писали production код без полного въезжания в архитектуру системы в целом.

I>Я знаю, только когда уходит топ, он уносит с собой несколько лет опыта и заменить его хотя бы частично за месяц-два-три просто нельзя.

Что значит уносит несколько лет опыта? Звучит как-будто забирает с собой ихсодники и часть мозга коллег. Вообще-то есть куча методик распространения опыта в команде, чтобы уход одного из разработчиков, даже ведущего, не был критичным для проекта.

I>А продакшн код обычно довольно быстро начинают писать. Только ответсвенность разная.

Получается что "веъжание" в проект есть принятие максимальной отвественности? Такое во многих случаях просто не нужно.

G>>>>Так всетаки мало платите, и ваши слова о 30%-50% ЗП выше среднерыночной — фикция.

I>>>Ты слишком много додумываешь. Не надо привносить свои проекции.
G>>Так это данные с сайта соспоставленные с твоими словами. Я вообще ничего не придумал.
I>Постоянно додумываешь.


I>>>Не каждый, но во первых, таких здесь очень мало, в Москве их гораздо больше.

G>>ну да, потому что в Минске им и 2000$ не платят, а в москве сразу 3000$ могут дать + потенциал есть. Это слихвой окупает разницу по стоимости проживания.
I>Вот про что я тебе и говорю.
Это то про что я говорю, платите мало. А вы постоянно утверждаете что создаются все условия чтобы люди не уходили.
Re: Что меня не устраивает в МП в Nemerle
От: Константин Л. Турция  
Дата: 25.12.08 21:12
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Дисклеймер:

AVK>1) Все сказанное ниже это мое личное мнение в моих конкретных условиях. На истину я не претендую.
AVK>2) Все сказанное относится только и исключительно к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков.
AVK>3) Попытки обсудить меня лично, мою квалификацию, опыт или мое психическое и психологическое состояние, а так же прочие медицинские и моральные вопросы, аутоматично приводят к тому, что попытавшиеся товарищи идут в лес.

AVK>Итак, сабж.

AVK>1) На практике я наблюдаю, что даже новые стандартные фичи языка используются очень и очень неспешно и с неохотой. Даже итераторы, которые еще в 2004 году появились, у многих вызывают изумление. Исходя из этого, я считаю, что серьезные изменения в самом языке, заточенные под конкретный проект, в промышленном программировании в большинстве случаев неприемлемы. И только в очень больших платформах, там где сейчас применяются собственные языки программирования, внесение изменений в язык на уровне платформы может быть оправдано.

можно разобью на 2?

1. новые фичи осваиваются неохотно
2. для пром. девелопмента лучше следовать стандартам, вольности неоправданы

соглашусь частично только со 2м, тк если отталкиваться от п.1, то прогресс нафиг не нужен. макросы действительно хорошая штука, чтобы превратить код в кошмар. но я видел, как это делали используя обычные языки через жопу.

AVK>При этом, обращаю внимание, ничего против того, чтобы использовать идеологию Немерле для построения собственно языка под конкретный стандарт я не имею. Т.е. суть не в конкретной технологии, а в области ее использования.

AVK>Итого — внесение изменений в компилятор для улучшения языка лично для меня с точки зрения промышленного программирования малополезно (при этом побаловаться для проектов, рассчитаных на одну-две хари фо фан я как бы и не против).
AVK>2) Еще одна сфера применения МП — создание DSL. И здесь есть имеем другую проблему — основной смысл применения DSL в моем случае — не расширение возможностей существующих языков, а наоборот, их сужение и жесткое ограничение заданными рамками. Для того чтобы минимизировать спектр возможных проблем и объем знаний, требуемх для использования. И для этого, как мне видится, хоть Nemerle и можно использовать, но подходит он для этих целей не очень, потому что даже его база весьма и весьма функциональна, хоть и маленькая совсем, а написание кода, проверяющего, нет ли чего лишнего в AST, очень непростая задача.
AVK>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.

пожалуй, но у немерле есть 2 преимущества: отсутствие интеропа, и компиляция, а не интерпретация, чем занимается большинство dsl (разве нет?).

AVK>3) Следующая сфера применения кодогенерации (язык не поворачивается назвать это метапрограммированием) — визарды в средах разработки, которые генерируют первоначальный код. Не очень представляю, как тут может помочь Немерле, да и использование специального языка тут явно перебор.


а что делать, если генерировать код нужно для имеющихся типов, дополняя их?

AVK>4) Генерация кода на основе DSL. Пример такого применения — DSL Tools. Вот здесь, в принципе, отчасти использование Немерле оправдано. Но есть тут одна засада. Дело в том, что разработка кодогенератора (любого, в том числе и по AST, с применением квазицитирования, паттерн-матчинга и алгебраических типов данных) нередко значительно сложнее, нежели написание генерируемого кода. И при поддержке, далеко не факт, что правка кодогенератора проще, чем модификация рукопашного кода при помощи современных средств рефакторинга.


не знаком с DSL Tools, так что тут промолчу

AVK>5) Последний момент, который я хотел обсудить — это АОП, или даже, в более широком смысле, инструментирование и ускорение кода. Я понимаю, что ситуации могут быть разными, и наверное тот же BLToolkit выиграет от портирования на Немерле. Но вот в моих задачах сей процесс нужно проводить не при компиляции, а в момент деплоймента. Поясню: инструментируемый код представлен в виде бинарников и я не имею права требовать перекомпиляции прикладного кода, если у меня вдруг произошли изменения в сервере, которые требуют генерируемый код изменить. Соответственно, compile time техники Немерле тут совсем не подходят, просто потому что никаких исходников, которые Немерле будет компилировыать, нет.


AVK>P.S. Еще раз, если кто то в корне со мной не согласен, прежде чем бросаться писать возмущенный ответ и разгромить меня в пух и прах, обратите внимание на наличие и содержание дисклеймера.
Re: Что меня не устраивает в МП в Nemerle
От: alvas  
Дата: 25.12.08 21:22
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Что подразумевается под словами "в моих задачах"? Из теста видно что это

Все сказанное относится только и исключительно к промышленному программированию в составе команд с размером > 3 человек и состоящих не исключительно из топа разрабочиков.


Я правильно понял?
http://alvas.net — Аудио-инструменты для .Net разработчиков
Re[2]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 21:30
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>1. новые фичи осваиваются неохотно


Скажем так, это стоит дополнительных денег.

КЛ>2. для пром. девелопмента лучше следовать стандартам, вольности неоправданы


Не очень понятно, если честно. При чем тут вольности? Выглядит как какая то эмпирика, а не истинная причина.

КЛ>соглашусь частично только со 2м, тк если отталкиваться от п.1, то прогресс нафиг не нужен.


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

КЛ>макросы действительно хорошая штука, чтобы превратить код в кошмар. но я видел, как это делали используя обычные языки через жопу.


Я ничего нигде не говорил о возможности превращения кода в жопу, это все очень субъективно. Дело не в этом.

AVK>>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


КЛ>пожалуй, но у немерле есть 2 преимущества: отсутствие интеропа


Ммм, а где в вышеприведенных технологиях интероп?

КЛ>, и компиляция, а не интерпретация, чем занимается большинство dsl (разве нет?).


Бывает ну очень по разному, и компиляция, и интерпретация, и вообще отсутствие выполнения в традиционном смысле. Тут надо понимать, что понятие DSL может быть очень широким, не обязательно это императивный универсальный язык. DSL Tools, к примеру, создает графические декларативные DSL (в качестве примера — редакторы Linq2SQL и EF объектов, редакторы UML в VS2010).
Если же наш DSL это универсальный текстовый язык описания алгоритмов с широким спектром возможностей, просто подрихтованый для специфических задач, то да, Nemerle-подобные технологии в подобном разрезе вполне интересны.

КЛ>а что делать, если генерировать код нужно для имеющихся типов, дополняя их?


В случае C# есть partial types и partial methods. Визарды не предназначены для повторных вызовов, если такое требуется, то это уже п.1.

КЛ>не знаком с DSL Tools, так что тут промолчу


Да дело то не в DSL Tools, а в создании генераторов сложных алгоритмов по простому описанию — генераторы моделей, парсеров и т.п.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[2]: Что меня не устраивает в МП в Nemerle
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.12.08 21:39
Оценка:
Здравствуйте, alvas, Вы писали:

A>Что подразумевается под словами "в моих задачах"?


Хм, по моему это вполне по русски. Подразумевается, что речь идет о тех задачах, с которыми сталкивался и сталкиваюсь именно я, и на глобальные обобщения на всю софтописательную индустрию и тенденции ее развития я не претендую. Что именно непонятно?

A>Я правильно понял?


Странный вопрос. Не знаю я, как ты понял.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[3]: Что меня не устраивает в МП в Nemerle
От: Константин Л. Турция  
Дата: 25.12.08 21:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:


КЛ>>1. новые фичи осваиваются неохотно


AVK>Скажем так, это стоит дополнительных денег.


стоп. мне казалось, что ты имел ввиду косность мышления и тп. Какие нужны средства, чтобы сотрудники начали писать декларативный код с пом. линка, вместо циклов и массивов?

КЛ>>2. для пром. девелопмента лучше следовать стандартам, вольности неоправданы


AVK>Не очень понятно, если честно. При чем тут вольности? Выглядит как какая то эмпирика, а не истинная причина.


Вольности, это клепать фреймворки и dsl-и на каждый чих

КЛ>>соглашусь частично только со 2м, тк если отталкиваться от п.1, то прогресс нафиг не нужен.


AVK>Почему не нужен? Не нужен глобальный прогресс в рамках конкретного прикладного решения, особенно если это решение не значительных размеров, не более того.


при чем тут мп от немерле?

КЛ>>макросы действительно хорошая штука, чтобы превратить код в кошмар. но я видел, как это делали используя обычные языки через жопу.


AVK>Я ничего нигде не говорил о возможности превращения кода в жопу, это все очень субъективно. Дело не в этом.


при том, что они дают возможность отойти от стандартов. за это, в первую очередь, его и ругают. этого ты и не одобряешь, имхо

AVK>>>Короче, идеология, применяемая в MPS, DSL Tools, Oslo для этой задачи представляется мне более подходящей.


КЛ>>пожалуй, но у немерле есть 2 преимущества: отсутствие интеропа


AVK>Ммм, а где в вышеприведенных технологиях интероп?


ок, гарантированное отсутствие интеропа. этими тулами dsl не заканчиваются, правда?

КЛ>>, и компиляция, а не интерпретация, чем занимается большинство dsl (разве нет?).


AVK>Бывает ну очень по разному, и компиляция, и интерпретация, и вообще отсутствие выполнения в традиционном смысле. Тут надо понимать, что понятие DSL может быть очень широким, не обязательно это императивный универсальный язык. DSL Tools, к примеру, создает графические декларативные DSL (в качестве примера — редакторы Linq2SQL и EF объектов, редакторы UML в VS2010).

AVK>Если же наш DSL это универсальный текстовый язык описания алгоритмов с широким спектром возможностей, просто подрихтованый для специфических задач, то да, Nemerle-подобные технологии в подобном разрезе вполне интересны.

КЛ>>а что делать, если генерировать код нужно для имеющихся типов, дополняя их?


AVK>В случае C# есть partial types и partial methods. Визарды не предназначены для повторных вызовов, если такое требуется, то это уже п.1.


какие у partial types есть инструменты для анализа окружения? В немерле для этого есть