Информация об изменениях

Сообщение Re[19]: Nemerle через 5 лет - выстрелит или скончается? от 29.09.2014 21:41

Изменено 29.09.2014 22:10 bazis1

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

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


B>>Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных.

WH> Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Браво, наконец нашли хороший пример. Это шаг в правильном направлении, но одного этого примера мало. Если вы хотите успеха и популярности, вам надо:
1) Найти штук 10 таких примеров
2) Сделать так, чтобы ваш язык работал поверх C#. Т.е. чтобы я мог добавить какой-нибудь хитрый аттрибут в свою C#-программу, который C#-компилятор проигнорирует, потом Nemerle-компилятор его обработает и добавит в мою сборку пару классов/методов. Тогда я (абстрактный потенциальный пользователь):
а) буду знать что в случае проблем я могу всегда переписать руками бойлерплейт и вернуться к обычному C#. Страховка, если хотите.
б) не буду платить за то, чем не пользуюсь. Т.е. для задач, где мне комфортно использовать C# я буду использовать C#. А как только наткнусь на подобный ботлнек, возьму столько немерла, сколько мне нужно.
в) Написать несколько статей не в духе "об оптимальной реализации макросов, Тьюринг-полных на момент компиляции", а в стиле "вот эта фигня, которая на C# делается за 5 минут с нашей перделкой делается в один клик".
г) быть готовым к скептическим вопросам. Например, касательно INotifyPropertyChanged я бы поспорил, что:

1. Имплементация INotifyPropertyChanged лично у заняла меньше 15 минут суммарно за 5 лет разработки на C#. Переходить на новый язык для экономии 15 минут за 5 лет было бы довольно странно.
2. Есть продукты, которые это автоматизируют без риска перехода на новый язык.
3. Если меня одолеет непреодолимая тяга подрочить на фреймворки к экспериментаторству, то я сделаю обертку через Reflection.Emit, которая будет генерить классы-наследники, имплементирующие этот интерфейс, и создавать их через MyStubFactory.Create<MyClass>() наподобие того, как сделан Remoting.
Re[19]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:

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


B>>Я никогда не копипастю (ну кроме proof-of-concept кода, который пишется на один раз), я просто умею применять стандартные механизмы типа того же наследования, которые позволяют избавится от копипасты без перехода на новый язык. И от людей, рекламирующих новое "средство от копипасты" ожидаю наглядной демонстрации, чем их средство лучше стандартных.

WH> Нука покажи, как ты не будешь копипастить реализацию INotifyPropertyChanged.
Браво, наконец нашли хороший пример. Это шаг в правильном направлении, но одного этого примера мало. Если вы хотите успеха и популярности, вам надо:
1) Найти штук 10 таких примеров
2) Сделать так, чтобы ваш язык работал поверх C#. Т.е. чтобы я мог добавить какой-нибудь хитрый аттрибут в свою C#-программу, который C#-компилятор проигнорирует, потом Nemerle-компилятор его обработает и добавит в мою сборку пару классов/методов. Тогда я (абстрактный потенциальный пользователь):
а) буду знать что в случае проблем я могу всегда переписать руками бойлерплейт и вернуться к обычному C#. Страховка, если хотите.
б) не буду платить за то, чем не пользуюсь. Т.е. для задач, где мне комфортно использовать C# я буду использовать C#. А как только наткнусь на подобный ботлнек, возьму столько немерла, сколько мне нужно.
в) Написать несколько статей не в духе "об оптимальной реализации макросов, Тьюринг-полных на момент компиляции", а в стиле "вот эта фигня, которая на C# делается за 5 минут с нашей перделкой делается в один клик".
г) быть готовым к скептическим вопросам. Например, касательно INotifyPropertyChanged я бы поспорил, что:

1. Имплементация INotifyPropertyChanged лично у заняла меньше 15 минут суммарно за 5 лет разработки на C#. Переходить на новый язык для экономии 15 минут за 5 лет было бы довольно странно.
2. Есть продукты, которые это автоматизируют без риска перехода на новый язык.
3. Если меня одолеет непреодолимая тяга подрочить на фреймворки к экспериментаторству, то я сделаю обертку через Reflection.Emit, которая будет генерить классы-наследники, имплементирующие этот интерфейс, и создавать их через MyStubFactory.Create<MyClass>() наподобие того, как сделан Remoting.

Дополнение: пример с INotifyPropertyChanged был бы в 10 раз убедительней, будь он представлен в течение года после появления WPF. Когда мысль "блин, как же INotifyPropertyChanged достал" возникала в голове у многих людей, осваивающих этот фреймворк. Сейчас каждый эту проблему для себя решил. Кто-то, смирившись, кто-то, наняв кодера за $15/час, кто-то с помощью стороннего продукта, кто-то, написав свой костыль... Поэтому ищите применения среди новых и быстрорастущих технологий. Пример с потолка: язык высокого уровня, который может компилироваться как в .Net-овские сборки, так и в Dalvik VM bytecode для исполнения на Android. ВНЕЗАПНО куча людей, которых не устраивает Mono, будут заинтересованно тыкать палкой в ваш продукт.