Здравствуйте, Ziaw, Вы писали:
А>>>2. Верните синтаксис обратно к корням: А>>> а. Поддержите синтаксис объявления Type instance вместо instance : Type. А>>> б. Замените def на var.
M>>Кстати, да. Не совсем понятно, в чём преимущество перестановки? Если можно сделать "как у всех", лучше сделать стандартно. Тогда Сишарповый код будет портироваться на ура тупо заменами подстрок. Z>instance : Type — тянется давно и не такая уж страшная вещь, чтобы изза нее не переходить на новый язык.
+1, по-началу непривычно, но, попользовавшись, могу признать, что так даже лучше. Но если удастся сделать и так и так — будет очень сильное лекарство против одной из фобий.
Z>def иммутабельный, var мутабельный. Будет вводить в заблуждение. Если хочется можно сделать макросом.
В скале как-то лучше получилось: var и val кажется. А def/mutable как-то вроде совсем-совсем о разном. тогда уж immutable/mutable или даже def/var (var для изменяемых, как и в шарпе).
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, IT, Вы писали:
А>> б. Замените def на var. IT>Тогда уже mutable на var.
IT>По этому поводу в своё время было много баталий в гугл группе. Главный аргумент — mutable использовать вообще плохо, лучше использовать def. А т.к. mutable режет глаз, то это как бы вынуждает как можно чаще пытаться использовать def. Если поменять mutable на var, то def использовать никто не будет. В общем, такой как бы воспитательный момент.
Глупости. Без mutable вообще не обойтись. Если этот факт не верный, то mutable надо убрать, а если верный, то не нужно искусственно усложнять. Зато когда человек уже начнёт пользоваться Немерле, что плохого, если первое время он будет всюду вставлять var? Функциональный фреймворк и язык с большим количеством функциональных конструкций сам натолкнёт на то, что "var не нужен".
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>В скале как-то лучше получилось: var и val кажется.
Это хуже, а не лучше. Ключевые слова на первый взгляд очень похожи (сливаются). Заметить разницу очень не просто. Тогда уж var/def.
_FR>А def/mutable как-то вроде совсем-совсем о разном. тогда уж immutable/mutable или даже def/var (var для изменяемых, как и в шарпе).
var будет провоцировать использовать изменяемые переменные не по делу. mutable — это как член на лбу. Незаметить невозможно. Следовательно программист видет где в его коде может быть опасность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _FRED_, Вы писали:
IT>>По этому поводу в своё время было много баталий в гугл группе. Главный аргумент — mutable использовать вообще плохо, лучше использовать def. А т.к. mutable режет глаз, то это как бы вынуждает как можно чаще пытаться использовать def. Если поменять mutable на var, то def использовать никто не будет. В общем, такой как бы воспитательный момент.
_FR>Глупости. Без mutable вообще не обойтись.
Это не глупости, а чистая правда. Иногда mutable нужен, но это довольно редкое явление. Чем более полно ты использоуешь немерловые средства, тем реже тебе становится нужен mutable. Так что количество mutable на квадратный милиметр кода как бы является показателем качества кода. Чем он ниже, тем лучше.
_FR>Если этот факт не верный, то mutable надо убрать, а если верный, то не нужно искусственно усложнять.
Тут можно провести аналогию с checked/unchecked. Нужны они крайне редко, но иногда нужны. Так что это не повод выкидывать их из языка.
_FR>Зато когда человек уже начнёт пользоваться Немерле, что плохого, если первое время он будет всюду вставлять var?
Ничего. Плохо то, что он может на этом и остановиться. А язык он должен подталкивать к более чистому и правильному коду.
_FR>Функциональный фреймворк и язык с большим количеством функциональных конструкций сам натолкнёт на то, что "var не нужен".
Как показывает практика чисто визуальное отличие для людей является большим стимулом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
IT>>>По этому поводу в своё время было много баталий в гугл группе. Главный аргумент — mutable использовать вообще плохо, лучше использовать def. А т.к. mutable режет глаз, то это как бы вынуждает как можно чаще пытаться использовать def. Если поменять mutable на var, то def использовать никто не будет. В общем, такой как бы воспитательный момент. _FR>>Глупости. Без mutable вообще не обойтись. VD>Это не глупости, а чистая правда. Иногда mutable нужен, но это довольно редкое явление. Чем более полно ты использоуешь немерловые средства, тем реже тебе становится нужен mutable. Так что количество mutable на квадратный милиметр кода как бы является показателем качества кода. Чем он ниже, тем лучше.
Если я хоть что-то понимаю в логике, то из того, что "Без mutable вообще не обойтись" и "количество mutable на квадратный милиметр кода как бы является показателем качества кода" говорит о том, что как не старайся, но качественного кода написать невозможно, ибо так как без изменяемых переменных нельзя и "редко", но они нужны
_FR>>Если этот факт не верный, то mutable надо убрать, а если верный, то не нужно искусственно усложнять. VD>Тут можно провести аналогию с checked/unchecked. Нужны они крайне редко, но иногда нужны. Так что это не повод выкидывать их из языка.
Аналогия мне кажется неуместна.
_FR>>Зато когда человек уже начнёт пользоваться Немерле, что плохого, если первое время он будет всюду вставлять var? VD>Ничего. Плохо то, что он может на этом и остановиться. А язык он должен подталкивать к более чистому и правильному коду.
Я очень уважаю srp, ибо образ, созданный Борисовым в "за двумя зайцами" показателен более чем. Мне кажется, что для завоевания пользователей более полезным было бы сосредоточиться на желаниях программистов, даже в чём-то подыгрывая им. С точки зрения необоходимости в продвижении, популизации языка утверждать, что "вот мы-то вас научим переучим программировать такими методами, что писать не правильно, так как вы привыкли, вам будет неуютно" очень смело Перетащить какую-то долю мейнстрима без "рекламных ходов" кажется невозможным: или делайте язык более удобным для освоения его программистами (и только тогда они будут его осваивать) или делайте язык для программистов, которые очень хотят на нём программировать и смогут это сделать. Я не понимаю, как можно добиться и того и другого одновременно.
Такие умные и все из себя функциональные, как вы, могут использовать неудобное (для самого же себя) mutable, дабы не расслабляться. Да пожалуйста. А все остальные зачем должны страдать какое-то время (пока не постигнут Дао иммутабельности)? Вы уверены, что люди считают, что им это нужно? Поэтому такие экстримистские, как бы я их назвал, подходы кажутся обречёнными на провал. Но это не страшно, благодаря ошибкам Немерле может появиться что-то популярное. Поэтому, для истории, может и ваша строгость окажется чем-то полезной
_FR>>Функциональный фреймворк и язык с большим количеством функциональных конструкций сам натолкнёт на то, что "var не нужен". VD>Как показывает практика чисто визуальное отличие для людей является большим стимулом.
Мне кажется, что практика показывает, что в том виде, в котором Немерле есть, он очень мало кому нужен. Это неоспоримый факт. И стимуляция "визуальными отличиями" как бы ни к чему не приводит (ибо ещё не привела). Не нужно фантазировать, нужно отталкиваться от реалий. Или не ныть по поводу фобий у большого количества программистов.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, VladD2, Вы писали:
_FR>>В скале как-то лучше получилось: var и val кажется. VD>Это хуже, а не лучше. Ключевые слова на первый взгляд очень похожи (сливаются). Заметить разницу очень не просто.
Это ключевые слова используются внутри методов (то есть не при описании интерфейса класса). Этот код уже читается несколько внимательнее. Большого значения при чтении написанного кода эта разница не имеет. Конечно это лишь моё субъективное мнение. Но чтению исходников скалы это различие не мешает ни сколько.
VD>Тогда уж var/def. _FR>>А def/mutable как-то вроде совсем-совсем о разном. тогда уж immutable/mutable или даже def/var (var для изменяемых, как и в шарпе). VD>var будет провоцировать использовать изменяемые переменные не по делу. mutable — это как член на лбу. Незаметить0 невозможно. Следовательно программист видет где в его коде может быть опасность.
Ну это мы в соседней ветке решим
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, IT, Вы писали:
_FR>>Глупости. Без mutable вообще не обойтись.
IT>Я тоже так когда-то думал.
А зачем тут думать? Почему бы не посмотреть в исходники Немерля? И удалить его вообще. ИМХО, будет только лучше. Во второй версии может отказаться от него вовсе? Что мешает?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Если я хоть что-то понимаю в логике, то из того, что "Без mutable вообще не обойтись" и "количество mutable на квадратный милиметр кода как бы является показателем качества кода" говорит о том, что как не старайся, но качественного кода написать невозможно, ибо так как без изменяемых переменных нельзя и "редко", но они нужны
Качественный код — это сферокнь вакумный. У понятия качество есть много составляющих. Одна из них скорость. Императивный код иногда может позволить поднять скорость. А стало быть и mutable вещь необходимая.
Плюс иногда императивные решения бывают тоже хорошими. Но все же значительно реже.
В общем, большое количество mutable — это четки показатель не лучшего по качеству кода. Для начинающего это нормально. Но со временем объем mutable должен снижаться. Если это не так — это четко демонстрирует отсутствие прогресса в изучении языка.
_FR>>>Если этот факт не верный, то mutable надо убрать, а если верный, то не нужно искусственно усложнять. VD>>Тут можно провести аналогию с checked/unchecked. Нужны они крайне редко, но иногда нужны. Так что это не повод выкидывать их из языка.
_FR>Аналогия мне кажется неуместна.
Чем же это? Полная аналоги. Без фичи нельзя, но используется она не часто, частая ее использование почти наверняка указывает на низкое качество кода.
_FR>Я очень уважаю srp, ибо образ, созданный Борисовым в "за двумя зайцами" показателен более чем. Мне кажется, что для завоевания пользователей более полезным было бы сосредоточиться на желаниях программистов, даже в чём-то подыгрывая им.
Дизайн языка — это тонкий процесс. Тут очень легко впасть в крайности. Идя на поводу у популизма очень легко сделать "грязный" язык которым никто не захочет пользоваться.
_FR>С точки зрения необоходимости в продвижении, популизации языка утверждать, что "вот мы-то вас научим переучим программировать такими методами, что писать не правильно, так как вы привыкли, вам будет неуютно" очень смело Перетащить какую-то долю мейнстрима без "рекламных ходов" кажется невозможным: или делайте язык более удобным для освоения его программистами (и только тогда они будут его осваивать) или делайте язык для программистов, которые очень хотят на нём программировать и смогут это сделать. Я не понимаю, как можно добиться и того и другого одновременно.
Согласен, это сложно. Но надо стараться. Возможно лучшим выходом будет создать два диалекта языка. И какой выживет, такой выживет. Технологии создаваемые под N2 это позволят (без сильных затрат сил и времени).
_FR>Более мудрым был бы шаг сначала завоевания большого числа пользователей, а потом уже [аккуратное!] привитие им кульных навыков.
Идеи не наши, и идеи очень даже правильные.
В общем, я согласен с тобой что некоторая доля популизма возможно и была бы полезна для распространения. Но вот в мере этого популизма я не уверен.
Возможно введение var и было бы оправдано. Но вот использование val вместо def — это плохая идея. Все же между изменяемыми и неизменяемыми переменными должна быть явная синтаксическая разница.
Кстати, одна из причин почему в C# редко используют неизменяемые поля — "длинный" синтаксис их объявления. В Немерле все с точностью до наоборот. По умолчанию (без дополнительных модификаторов) получается неизменяемое поле. И это очень здорово! Программист создает неизменяемые поля даже не задумываясь. И часто они таковыми и остаются. Ну, а если ему требуется изменяемость, то рано или поздно программист получает сообщение от компилятора и меняет объявление. Это заставляет его задумываться над тем нужна ли ему изменяемость.
_FR>Такие умные и все из себя функциональные, как вы, могут использовать неудобное (для самого же себя) mutable, дабы не расслабляться. Да пожалуйста. А все остальные зачем должны страдать какое-то время (пока не постигнут Дао иммутабельности)?
Дело в том, что неудобство mutable — это еще одна фобия. "mutable" комплитится с двух букв. Так что при написании это проблем не вызывает. Ну, а то что mutable лучше выделяется от этого только польза. Кто не хочет лучше видеть объявления переменных? Со временем приходит и понимание того, что mutable много быть не должно.
_FR>Вы уверены, что люди считают, что им это нужно? Поэтому такие экстримистские, как бы я их назвал, подходы кажутся обречёнными на провал. Но это не страшно, благодаря ошибкам Немерле может появиться что-то популярное. Поэтому, для истории, может и ваша строгость окажется чем-то полезной
Вот в Шарпе появилось ключевое слово override. Оно тоже "удлиняло" синтаксис. Кое кто по началу ворчал от этого. Но так как от этого на практике были только плюсы (люди перестали ошибаться в переопределении методов), то все быстро к этому привыкли.
Думаю, что так как фарш уже невозможно провернуть назад (первая версия выпущена), то нужно просто постараться донести до программистов причины такого выбора. Разумные все пойму. Кто-то особо вредный может сделать для себя макрос. А совсем неадекватные пусть подрастают морально. Им пока этот язык не нужен. У нас, в конце концов, нет задача переманить на свою сторону всех манки-индо-девелоперов.
_FR>Мне кажется, что практика показывает, что в том виде, в котором Немерле есть, он очень мало кому нужен. Это неоспоримый факт. И стимуляция "визуальными отличиями" как бы ни к чему не приводит (ибо ещё не привела). Не нужно фантазировать, нужно отталкиваться от реалий. Или не ныть по поводу фобий у большого количества программистов.
Откровенно говоря люди которые отказываются от языка из-за разницы в одном идентификаторе — это очень ограниченные люди и биться за них глупо. Лично я уверен, что mutable не является основной причиной неприятия.
Вот рядом товарищ сокрушается, что синтаксис для него пе понятный. Вот его я понять могу. Ведь под синтаксисом он понимает очень даже не тривиальные отличия — паттерн-матчниг. Вот за таких надо бороться. От них будет толк.
ЗЫ
Во второй версии попробуем сделать два языка. Один прямой наследник немрела, а другой почти полный супер-сет шарпа (за вычетом некоторых явных промахов в дизайне которые мешают расширяемости или еще чему-то). Оба языка можно будет применять в рамках одного проекта. Можно будет даже сделать конвертер из одного в другой и обратно. Возможно это что-то даст. Поглядим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
_FR>>Глупости. Без mutable вообще не обойтись.
IT>Я тоже так когда-то думал.
Мартин Одерски "Programming in Scala", 1-е издание, chapter 22 "Implementing Lists":
22.5 Conclusion
In this chapter, you saw how lists are implemented in Scala. List is one of the most heavily used data structures in Scala, and it has a refined implementation. List’s two subclasses, Nil and ::, are both case classes. Instead of recursing through this structure, however, many core list methods are implemented using a ListBuffer. ListBuffer, in turn, is carefully implemented so that it can efficiently build lists without allocating extraneous memory. It is functional on the outside, but uses mutation internally to speed up the common case where a buffer is discarded after toList is been called. After studying all of this, you now know the list classes inside and out, and you might have learned an implementation trick or two.
Здравствуйте, _FRED_, Вы писали:
_FR>Это ключевые слова используются внутри методов (то есть не при описании интерфейса класса).
Для немерла — это не так. "mutable" используется и при объявлении полей. По умолчанию поля неизменяемые.
_FR>Этот код уже читается несколько внимательнее. Большого значения при чтении написанного кода эта разница не имеет. Конечно это лишь моё субъективное мнение. Но чтению исходников скалы это различие не мешает ни сколько.
Пойми — код методов — это самый объемный код в проектах. Чем меньше надо напрягаться при его чтении, тем проще жить программисту. Усложнять его в угоду популизму — это значит заведомо делать язык хуже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
А>>1. Переименуйте Nemerle в C#+. Или C&&. Или AltSharp. Или CNext. Или C.Net.
L>Даешь Ня! Это будет достойный ответ Boo (Фу).
Предложить что ли скалу в J++ какой-нить переименовать?.. Вообще, большинство прозвучавших в этой ветке предложений "по раскрутке" — из серии "вы не так сидите". Какая к чёрту разница, как он называется? Я вот тут читаю про mutable и не только, давно уже на этот форум подписался, и чувствую, что с перфекционистами каши не сваришь — они могут в N2 от N1 камня на камне не оставить. Какую-то ещё вторую версию синтаксиса — суперсет C# 4 — собираются ваять. Получается, либо ребята до сих пор не определились с синтаксисом, либо им натурально больше нечем заняться (что, как известно, очень сильно далеко от правды). В обоих случаях тема ветки очень, знаете ли, к месту.
Здравствуйте, Lloyd, Вы писали:
А>>1. Переименуйте Nemerle в C#+. Или C&&. Или AltSharp. Или CNext. Или C.Net.
L>Даешь Ня! Это будет достойный ответ Boo (Фу).
Может тогда "Нах"?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
А>>1. Переименуйте Nemerle в C#+. Или C&&. Или AltSharp. Или CNext. Или C.Net. L>Даешь Ня! Это будет достойный ответ Boo (Фу).
Nyamerle? "Nya, merle" (merle — "дрозд черный"; даже логотип можно будет не перерисовывать)?
А что, есть же язык "Racket"
Выскажусь и я, а то не дай бог добавите val, var, immutable или еще какую-нибудь чушь.
Меня синтаксис устраивает практически всем. Ну, разве что, необходимость ставить точку у дженериков, это досаждает. Когда изучал немерль напрягали параметры дженериков в квадратных скобках, но теперь привык. Но больше всего донимали глюки интеграции и компилятора (компилятора практически исчезли, интеграция стала тоже весьма стабильна).
Думаю, ты и сам понимаешь, что предложения навроде "Верните объявление типа перед переменной, как с C#" или "давайте заменим mutable на var" делаются просто от попыток перенести знакомые способы написания кода на Немерль. А Немерль предлагает другой подход, лучший. У меня самого были такие мысли, но я понял, что есть другой способ получить результат.
Не стоит идти на поводу у таких людей. immutable своей визуальной громоздкостью (несвойственной для Н) сразу привлекает внимание. И это очень правильно.
Это принципиальный вопрос, и идти в нем на поводу у людей, которые просто не очень понимают как пользоваться Н, нельзя.
Сейчас я бы с удовольствием писал на Немерле на работе, но проблема в том, что новых проектов не стартует, да я и простой разработчик, ни синьёр (чтоб померли эти все названия), ни архитектор, ни проджект менеджер и мое мнение всем по баяну.
А для своего домашнего проекта под Windows Phone я не могу Н использовать — компилятор под него не работает, увы.
Сейчас же меня в Н напрягает только одно — сложность написания макросов. Не столько интеллектуальная, сколько технологическая — где какой метод, почему это можно сделать в той стадии компиляции, а это нет, несогласованность соглашений об именовании (привет полякам) и т.д.
П.С. Вот бы кто мне помог с ComputationExpression (мне надо понять, как там перехватывать состояние). Мне часто по работе приходится разные воркфлоу программировать, я бы попытался пробить использование Н.
F>Ну, разве что, необходимость ставить точку у дженериков, это досаждает.
+1
F>Это принципиальный вопрос, и идти в нем на поводу у людей, которые просто не очень понимают как пользоваться Н, нельзя.
У меня такое чувство, что основная критика Немерле исходит от людей, которые не написали на нем ни строчки, а в лучшем случае прочитали пару статей Влада. Вы сначала попробуйте написать что-либо более-менее сложное, а потом критикуйте.
или даже def/var (var для изменяемых, как и в шарпе).
Если нам не помогут, то мы тоже никого не пощадим.
Перетащить какую-то долю мейнстрима без "рекламных ходов" кажется невозможным: или делайте язык более удобным для освоения его программистами (и только тогда они будут его осваивать) или делайте язык для программистов, которые очень хотят на нём программировать и смогут это сделать. Я не понимаю, как можно добиться и того и другого одновременно.
Вы уверены, что люди считают, что им это нужно? 
Поэтому такие экстримистские, как бы я их назвал, подходы кажутся обречёнными на провал. Но это не страшно, благодаря ошибкам Немерле может появиться что-то популярное. Поэтому, для истории, может и ваша строгость окажется чем-то полезной 
