[Ann] VS14 Сtp0
От: Sinix  
Дата: 04.06.14 06:12
Оценка: 97 (10)
Сабж. Ещё подробности.

Если коротко — ранний билд VS с поддержкой всего, что наобещали
Автор: Sinix
Дата: 03.04.14
на //build/, включая RyuJIT, ef7 и asp.net vNext.

Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS (читай — лучше не рисковать и использовать для экспериментов виртуалку).

Из того, что точно будет интересно пощупать — интегрированный в VS roslyn compiler + c# 6 со всеми плюшками типа someVal?.ToString() ?? "".
Re[6]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 22.06.14 19:05
Оценка: 28 (5) +3
Здравствуйте, btn1, Вы писали:

B>Я не корю их за то, что такую тривиальщину не сделали до этого (хотя и могли). Я не понимаю, почему сейчас это отнимает столько времени!? Ты ж прогер, просто сядь за листок и набросай псевдокод — да там от силы 20 строк получится!


Прототипы писали, и там далеко не 20 строк. Начнём с того, что строковые литералы перестают быть монолитными токенами, и должны теперь содержать синтаксические узлы, которые могут представлять имя переменной (константы, поля, свойства...). Эти синтаксические узлы могут иметь собственные предупреждения/ошибки, которые не относятся к строке в целом (использование переменной до присваивания, доступ к экземплярному члену из статического контекста, использование Obsolete члена...). Также другие фичи, как, например, Find All References, Rename refactoring, Extract Method refactoring должны знать о наличии этого узла, и правильно его обрабатывать.

Ввиду того, что такие строки могут перестать быть constant expressions (ещё вопрос: может быть, они должны оставаться constant expresions, если все interpolated expressions — константы?), надо исправлять код, работающий с constant expressions, и с другими категориями "почти константных" выражений, как, например, аргументы атрибутов.

Каким образом значение interpolated expression должно преобразовываться в строку? С помощью вызова метода .ToString()? А если там null, то должно быть исключение, или пустая строка, или специальная строка "<null>"? А если объект скрывает виртуальный метод .ToString(), унаследованный от object, с помощью другого метода или свойства? Должна ли это быть ошибка, или мы должны попытаться вызвать этот метод или свойство (надеясь, что оно возвращает подходящий тип), или мы должны всё-таки вызвать скрытый базовый метод? А если intepolated expression имеет тип dynamic, должен ли это быть динамический вызов метода .ToString()? А затем, должен ли это быть динамический вызов оператора + в выражении "..." + d.ToString() + "..."? А окончательный тип выражения должен быть тоже dynamic, или мы должны динамически вызвать (возможно, user-defined) оператор приведения к string?

Если всё это встречается внутри expression tree, должны ли мы создать новый вид узлов для таких строк (и предоставить всем LINQ провайдерам самостоятельно разбираться с ними)? Или же мы должны создавать дерево, в котором эти строки представлены уже в раскрытом виде? Или просто запретить их в этом контексте (и добавить новое сообщение об ошибке)?

Нужно ли проправлять CodeDOM API? И т.д. (А то иначе ведь в Microsoft такие идиоты, в одном месте фичу с горем пополам приделали, а про остальные очевидные места, с которыми она связана, как всегда забыли...)
Re[2]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 04.06.14 12:57
Оценка: 10 (2) +4 :)
Здравствуйте, btn1, Вы писали:


B>Да эти клоуны и к 22 веку не напишут человеческий вывод строк!

String interpolation скорее заменяет string.Format, да и то частично. К выводу строк оно никакого отношения не имеет.

B>Да ё-моё! "String interpolation" всё ещё MAY BE?!?!!


А почитай обсуждение. До рослина никто бы этим не занимался (по понятным причинам). После — руки дошли только сейчас, да и то только потому, что остальное укладывается в сроки до релиза.

Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:

* Как объявлять такие строки — с префиксом $"Hi, {Name}!" или через "Hi, \{Name\}!"?
* Как экранировать скобки в первом случае: как в шарпе, или как в string.Format ("\{" vs "{{")?
* Что насчёт verbatium strings, не будет ли перебором $@"Hi, {Name}!"
* Допустимы ли выражения внутри "{Name}", или только идентификаторы? Вызов методов?
* Поддерживать ли этот формат в [DebuggerDisplay]? API для подобных атрибутов?
* Какая культура должна быть по умолчанию? Нужен ли способ явно указать культуру?
* Добавлять ли синтаксис форматирования от string.Format() ( $"{time:0.0##} second(s) left!")? Кидать ли ошибки при неверном синтаксисе?
* Нужна ли возможность заменить interpolator (штуку, которая будет раскрывать выражения в {})? Если да — какие сценарии надо учитывать — razor, sql-форматтеры, биндинг, ещё что-нибудь?
* Нужна ли функция обратного парсинга строки?
* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic?
* Как насчёт динамических строк, например, строк из ресурсных сборок?

ну и тд и тп.

Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай
Re[5]: [Ann] VS14 Сtp0
От: btn1  
Дата: 04.06.14 20:26
Оценка: -7
Здравствуйте, gandjustas, Вы писали:

G>Ответ на вопрос "зачем" — совместимость.


Это не самый главный критерий в языке, который сначала тупо переписали с Жабы, потом допилили, потом ещё допилили, а затем получился язык, который 100% не пойдёт на C# 1.0;
Эволюция языка не может идти идеально, если это не заранее продуманный язык. Или минималистичный как LISP. Тем более, что я уже написал:

Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).


Кто хочет — пусть пользуются новыми фичами. У кого код ломается — пусть сидит на C# 5.0; Но сидеть на старье только потому, что кто-то там себе в строках забубенил доллар — это тупость.

Да и что за пафос говорить о "совместимости", когда в системе уже стоит .NET 4.5.2 — наглядный пример непродуманности даже такой базовой вещи, как VM.
Re[18]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 21:45
Оценка: 2 (2) +2 -1 :)
Здравствуйте, kleng, Вы писали:

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


N>>Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?


K>Реализация кривая, и глупо с этим спорить.


Это не так. Реализация абсолютно правильная, и в точности соответствует международно принятой спецификации.

Дизайн перечислений, как он закреплён в спецификации, изначально являлся неоднозначным вопросом, и имел аргументы как за, так и против. Решение, которое было принято, выглядит вполне уместным: и с точки зрения перформанса, и с точки зрения возможности работать с битовыми флагами, и с точки зрения простого интеропа с существующими COM-интерфейсами. Решение выглядит, как не подлежащее изменениям, по причине необходимости поддержания обратной совместимости (даже если бы баланс аргументов за и против изменился с тех пор). Существуют альтернативные механизмы, позволяющие реализовать значения, принимающие только указанное множество объявленных значений (например, абстрактный класс с вложенными наследниками-синглетонами). Язык не вынуждает пользователя использовать енумы, если они не подходят для его задач.
Re[4]: [Ann] VS14 Сtp0
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.14 17:44
Оценка: 9 (1) +4
Здравствуйте, btn1, Вы писали:

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


B>Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.


Ответ на вопрос "зачем" — совместимость. Крайне необходимо чтобы 99,9999% существующих программ не поломались при введении новой фичи. Кроме того важно чтобы в дальнейшем, при необходимости фичу допилить, изменения не поломали 99,9999% существующих программ.
Re[6]: [Ann] VS14 Сtp0
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.14 21:27
Оценка: 9 (1) +4
Здравствуйте, btn1, Вы писали:

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


G>>Ответ на вопрос "зачем" — совместимость.


B>Это не самый главный критерий в языке

Увы, для мейнстримного языка — главный, как бы ни казалось обратное.

B>который сначала тупо переписали с Жабы, потом допилили, потом ещё допилили, а затем получился язык, который 100% не пойдёт на C# 1.0;

Это ты к чему написал? Сейчас оооочень много кода для C# 1.0 компилируется последней версией языка, не 100% но более 99% точно.

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

У C# получается, и стратегия такова что и будет получаться.
Для более маргинальных языков такое необязательно, что и демонстрирует F# делая ломающие изменения между мажорными релизами.

B>Тем более, что я уже написал:

B>

B>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).

Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?

B>Кто хочет — пусть пользуются новыми фичами. У кого код ломается — пусть сидит на C# 5.0; Но сидеть на старье только потому, что кто-то там себе в строках забубенил доллар — это тупость.

Фактически это означает что 90% будут сидеть на C# 5.0, это затормозит развитие фреймворков, что в свою очередь уронит продажи Visual Studio и серверных продуктов.

B>Да и что за пафос говорить о "совместимости", когда в системе уже стоит .NET 4.5.2 — наглядный пример непродуманности даже такой базовой вещи, как VM.

С VM проще, ничего не мешает иметь несколько VM внутри процесса side-by-side и даже делать прозрачный маршалинг между ними. При этом CLR4 совместим с CLR2, то есть может в свою ВМ грузить сборки под старый фреймворк, так что и на этом уровне совместимость очень тщательно поддерживается. Хотя это и не так важно.


Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6 (2006 год), а некоторые до сих пор используют Java 1.4. При этом с совместимостью у Java не сильно хуже, чем у C#.
Re[4]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 05.06.14 07:14
Оценка: 52 (4)
Здравствуйте, btn1, Вы писали:

B>Читал. Много думал — сколько же нужно ПИНКОВ ПОД ЗАД, чтобы эти тюлени хоть что-то написали!


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

Поскольку других разработчиков у MS для нас нет и btn1 по какой-то чудовищной ошибке ещё не нанят для исправления фатальных недостатков шарпа, приходится ограничиваться тем, что есть. А есть у нас следующее:

1. До .net 4 каждая версия шарпа дополнялась очередной big thing — согласованным набором возможностей, которые (это я сейчас без пафоса) кардинально упрощали реализацию той или иной типовой задачи. Генерики, linq + лямбды, dynamic, await etc, общее направление, думаю, понятно. При этом на мелкие фишки или на серьёзные доработки внутренностей компилятора время не выделялось за очень редкими исключениями — было банально не до них. Да и основному потребителю — энтерпрайзу — было как-то всё равно. На яве вон пишут и не жалуются

2. К моменту выхода .net 4 стали очевидны следующие вещи:
* Дальше добавлять возможности в компилятор весьма проблематично, потенциал для развития исчерпан. Дошло до того, что в vs фактически работало два компилятора — стандартный csc.exe + псевдокомпилятор для "живой" подсветки ошибок (который live semantic errors option).
* С выходом winphone/win8/xbox next c# начинает активно использоваться не только в Applications and Services division, но и для Operating Systems/Devices and Studios. Чтобы не потерять момент, нужна инфраструктура для быстрого развития языка.
* На примере VS 2010 стало очевидно, что managed api + расширяемость повышают качество продукта на порядок. Во-первых, часть рутины решается сторонними расширениями, во-вторых, можно экспериментировать, выкатывая пробные возможности как дополнения студии.
В общем, roslyn стал фактически неизбежен

3. Допиливание рослина от первого анонса до продакшна займёт три года — примерно тот же срок, что и между прошлыми крупными релизами языка. Делать в это время параллельно с рослином очередной big thing — самоубийство в чистом виде. Во-первых, никаких ресурсов не хватит (надо ещё выпустить vs12 и vs13), во-вторых, за эти три года типовые области разработки и актуальные задачи поменялись куда заметнее, чем за всё прошлое время с начала развития шарпа. Энтерпрайз потихоньку уходит в веб и облака, потребители на телефоны и планшетки — приходится очень аккуратно выбирать возможности, чтобы не протратить ресурсы впустую.

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

S>> До рослина никто бы этим не занимался (по понятным причинам)

B>?? Это по каким ещё причинам IS(interpolates strings) стали вдруг уникальной фишкой Рослина?? Это же обычный синтаксический сахарок!
B>Ну как бы фича-то ни бог весть какая уникальная и "свежепридуманная" — Руби с Перлом используют её уже как сто лет!
Угу. Но читай выше — у команды хватало дел и без подобной мелочёвки. Возни много, пользы мало (учитывая конкуренцию с string.Format). Тем более что можно и не добавлять ничего, только прикрутить валидацию к методам форматирования. JetBrains в решарпере с этим как-то справились, не померли

Ну а больше никаких принципиальных преимуществ у string interpolation нет.




B>Там нечего "ломать" — надо просто ввести новую функциональность. По вопросам охотно отвечу, но сразу сделаю Главное Замечание: IS — это не замена string.Format! Это просто фича "быстро и удобно вставить значение в строку" — с наиболее употребимыми умолчаниями и как можно более простым чтением. Соответственно, сразу отпадают неуместные вопросы:


S>>* Допустимы ли выражения внутри "{Name}", или только идентификаторы? Вызов методов?

S>>* Какая культура должна быть по умолчанию? Нужен ли способ явно указать культуру?
S>>* Добавлять ли синтаксис форматирования от string.Format() ( $"{time:0.0##} second(s) left!")? Кидать ли ошибки при неверном синтаксисе?
S>>* Поддерживать ли этот формат в [DebuggerDisplay]? API для подобных атрибутов?

Если они отпадают, то отпадают и ~70% сценариев использования. Подобное форматирование строк нужно разве что для лога, да и то не всегда. Для вывода пользователю нужна текущая культура + обычно форматирование берёт на себя биндинг в UI-фреймворке. Если запретить вызов методов, то придётся объявлять доп переменные вместо "Score: {GetScore()}" — ещё один минус, если сравнивать с string.Format().

B>Т.е. мы вводим фичу только для самых употребимых случаев: есть строка, в неё нужно вставить значение.

А дальше все её используют и развивать фичу нельзя, т.к. запорется совместимость.

B>Вариант с \{} — сразу в топку как неудобочитаемый. Вопрос только, а зачем вообще нужен префикс?? Что, старые строки нельзя "рассматривать по-новому"? Старый код — для него всегда можно ввести warning: "ваша строка похожа на новую фичу".


Нельзя. Ибо энтерпрайз и софт десятилетней давности должен собираться без подобных проблем. В вашем варианте будет примерно следующее: открываем такой мааленький проектик с использованием своего форматтера, получаем 8 258 варнингов после обновления компилятора. Дальше тратится примерно 4-10 часов на расследование и закрытие кейза ($200-$1000 для типовой компании). Умножаем на количество потенциально проблемных проектов, понимаем что лучше не связываться.

B>Наконец, был озвучен не самый плохой вариант с "ёлочками": « и » (и тогда отпадает конфуз с verbatim: @«»)

Не вопрос, осталось оснастить каждую клавиатуру этими ёлочками и заодно убедить кое-какие системы CI что исходники c# в ASCII — это таки XIX векъ и нѣплохо бъ обновiться.


B>Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать.

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


S>>* Нужна ли возможность заменить interpolator (штуку, которая будет раскрывать выражения в {})? Если да — какие сценарии надо учитывать — razor, sql-форматтеры, биндинг, ещё что-нибудь?

B>Не нужно. Это будет приятная фича языка для простой вставки значений, всё что свыше — overengineering.
Угу, т.е. для вывода в html, для подстановки параметров в sql-запросы и для биндинга фича не годится, ещё минус 10-20% от сценариев использования.

S>>* Нужна ли функция обратного парсинга строки?

B>Не понимаю терминологии. О чём речь?
TimeSpan now;
parse("Time {now:hh:mm:ss}", "Time 22:22:22");
WriteLine(now)



S>>* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic?

B>Надо смотреть конкретный пример — ни то, ни другое не используется широко в программах и поэтому вопрос, нужно ли вообще там что-то поддерживать.
Угу, т.е. форматирование строк ресурсов и динамический sql в orm-провайдерах тоже идут лесом, т.к. не нужны(tm).

Получается, делать interpolated string особого смысла нет. Можно хоть один пригодный для продакшна пример?

S>>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай


B>Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.

)) Начнём с того, что string.concat должен применяться только если не задано форматирование, $"Money {modey:N2}" через concat не сделаешь. Закончим тем, что в вашем варианте покрывается процентов 10 от возможных вариантов использования, причём остальные 90 в будущем не могут быть реализованы из-за подхода "чо там думать, кодить надо"
Re[10]: [Ann] VS14 Сtp0
От: QrystaL Украина  
Дата: 06.06.14 09:07
Оценка: 5 (1) +3
Здравствуйте, btn1, Вы писали:
B>Может, "альтернативный успех"?
Пользуюсь с первых дней, после апдейта 8.1.1 стало практически неотличимо от 7.
В продажах может и провал, а в остальном — проблем нет
Re[7]: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 16:53
Оценка: -4
Здравствуйте, Sinix, Вы писали:

S>Всё просто — MS не получает денег за добавление новых фич.


Если говорить о деньгах, получается мелкософт прямо облизывает своих клиентов "какие фичи вы хотите в следующем релизе? Ведь вы заплатили за студию — имеете право!" — так штоле? НЕ НАДО говорить о деньгах, когда речь идёт о техническом вопросе. Если деньгами всё измерять, тогда вообще этот Липперт с его блогом-отговорками не нужен — тупо посадите наглую обезьяну и пусть она всем отвечает: "Вы мне не заплатили за эту фичу!". Это не метод и не причина. Я даже больше скажу — НИКТО И НИКОГДА не покупал студию только потому, что в ней забабахали какую-то синтаксическую перделку (пусть даже уровня LINQ). Покупка — решение многогранное, вплоть до политических мотивов. Тогда к чему все эти рассуждения о "старых/новых клиентах"? Те платят только потому, что ХОТЬ КОМУ-ТО платить — а надо! Хоть Ораклу с его Жабой, хоть SAP'у. А единожды заплатив мелкософту и создав мелкомягкую инфраструктуру, контора по-жизни будет "висеть" на этом крючке и всё её будет удовлетворять.
Ну и раз уж мы затронули деньги, опять подыму вопрос: каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8? _ВСЕ_, от домохозяйки до программиста, знают — вышло полное гуано с абсолютно непотребным интерфейсом. Какие продажи ждут студию? О каких клиентах они там заботятся? Они кнопку "старт" ГОД ВОЗВРАЩАЛИ (и всё-равно, ^%#$%#^, не вернули!).

S>... добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка.


А как тут измеряется ВЫЙГРЫШ? Количество эндорфина на куб.см. мозга юзера? Количество продаж студии? Громкость хлопков при анонсе фичи? Я не понимаю, как можно "проигрывать" там, где ты тупо делаешь язык лучше!
Фичи можно как-то сравнить по полезности, но извини, что-то я не припомню никаких революций в мире C#, сильно облегчающих мне жизнь. Зато кучи маленьких, но необходимых вещей так и померли под отговорками тех, кто говнокодил до "эпохи Рослина".
Ну вот, скажем, инициализация автопроперти — что, дюже прорывная фича? Гендиректор обсуждает её с программистом "купим мы из-за неё студию"? Нет. Это просто ДЕЛАЕТ ЖИЗНЬ ЛУЧШЕ. Причём с первого взгляда — вроде бы глупость, но мы-то с тобой знаем, чем оборачивается отсутствие этой фичи — это ПЛЮС СЕМЬ ЛИШНИХ СТРОК КОДА к каждой проперти!!! А теперь покажи мне, что за охрененно важные фичи были сделаны ВМЕСТО этой?
Прям вас с Липпертом послушать — мелкософт-рабы с утра до ночи трудятся на благо студии и фичи у них как из мясорубки — лезут и лезут, делая жизнь прекраснее! Фиг-два, там сидят отъетые тюлени и тоже не особо спешат работать — ведь отговорки уже придуманы, чё париться?

S> Иначе язык или быстро превратится в помойку


Дело в том, что C# крайне далёк от "помойки" а-ля PL/1 (ты же в курсе его концепции?). Кроме того, просьб — тысячи, из них несложно составить более общий пакет запросов, покрывающий большую часть (т.е. будет не помойка, а оптимальный набор выразительных средств). Некоторые вещи вообще должны были идти автоматом, но увы — никакого "обилия фич" я не наблюдаю! Сто лет существуют проперти и только сейчас(!!) зашла речь об инициализации. Двести лет существуют multiple return values — в команде C# мы про это не услышим ещё 100 лет. Бинарные литералы — вообще основа основ!! Но нет, "эта фича не принесёт нам денег!" *произносится капризным тоном Липперта*
Перечислять можно долго, но суть-то очевидна: за всеми отговорками кроется одна простая вещь: жадность. От жадности быстро наговнокодили "Жабу в профиль". От жадности не дали толком разработать VM — вперёд, главное ввязаться, а там прорвёмся! От жадности не наняли толковых парней на хорошую зарплату — решили выехать на паре "профи" + 20 индусских мартышек. А дальше поехало по накатанной — запросы прут, но реализовать их без уборки костылей — никак, поэтому начинаются разные офигительные истории про клиентов, рентабельность, неоднозначность и прочую муру.

S>Тема обсуждалась сотни раз... Тем не менее, люди отказываются верить


...и правильно делают! Потому что деньги — не вопрос, специалистов — море, но M$ всё равно продолжает "кидать" юзеров. Нет времени? Ах вы, ***, бедненькие, в поту и крови пашете под палящим солнцем, жену-детей не видели пол-года! Так штоле? Нет. Сидят, крутят свои ж**ы в креслах, пьют кофе, рассуждают о выходных — обычная офисная работа! Нет рук? Я тя умоляю, НАЙМИ ЕЩЁ ЛЮДЕЙ, но только не индусов! Пройдёт пол-года и каждый член команды будет с лёгкостью факира выкатывать фичи. Или опять... "жадность"? Вот то-то же!
Не бывает так, что повозка "сама" не едет — либо лошадей мало, либо корм зажопил. Всё остальное — отговорки.

S>Даже про "20 строк кода" отвечалось неоднократно.


Прочёл. Забавно, но НИКАК не отвечает на вопрос, какого *** не сделаны фичи. Почти все упомянутые люди работают ОДНОВРЕМЕННО. Напомню, 5 дней в неделю, ежедневно приходя трудиться на 8 часов! Что тут сложного-то?? Тем более, когда каждый чих распределён аж на 16 _разных_ "чиховедов"! (и каждый "специализд" делает свою узенькую работу, не всегда занимающую даже час его времени)
То, что Липперт там перечислил — это НОРМАЛЬНЫЙ РАБОЧИЙ ПРОЦЕСС! Фича должна вылетать из уст, падать в механизм приёма фич и вылезать на выходе в виде сервиспака или расширения. Всех этих липпертов нанимали не ныть "как много мы обсуждаем фич", а РАБОТАТЬ — внутри отлаженного механизма "разработка компилятора".

S>Ну... за иронию извиняюсь, но тема действительно классическая.


ненене, в иронии всё правильно, просто почему бы не допустить, что я — не худший специалист, чем они? Ведь я-то как-то разглядел общий код! И ты, больше чем уверен, не раз рефакторил код, вынося общие функции, правильно? Ну так чего тогда ты молишься на идолов? Были бы они боги — Рослин был бы написан 10 лет назад, а раз не написан — значит бардак с их менеджментом наложился на посредственный состав команд, только и всего. А на месте Липперта я бы не позорился с отговорками, а просто деликатно объяснил, что существующий код сложно расширять вашими запросами.
Вот к чему приводит бестолковый менеджмент "одна команда пилит студию, а другая НЕЗАВИСИМО пилит компилятор" — задачи-то распределял дилетант!

S> Со стороны всё действительно просто. Копнёшь — лучше и не вкапываться было.


Я не сказал, что писать "просто" — я сказал, что при том времени, которое у них было на разработку, почти всё можно было сделать! 10 лет по 200 рабочих дней, 8 часов каждый, при практически неограниченных возможностях найма персонала и бесконечной технической базе. (плюс, опыт старых наработок времён первого Visual C++) Это и есть их работа — решать сложные задачи! И если решение было хорошее, дальнейшее расширение языка — просто песня Золушки!

S>...компиляция каждого метода выполнялась в ~26 проходов


Да хоть в 126! Ты уверен, что это было правильное решение? Что архитектура была продумана и 26 — минимально необходимое количество? Я — нет.

S>Т.е. добавлене каждой новой фичи (пусть и "в 20 строк") ещё ненамного замедляло общее время компиляции и добавляло минусов в копилку следующих фич — для них порог добавления становился ещё выше.


Это нормально — для говнокода. А что они хотели-то?? "Лучше день потерять, потом за 5 минут долететь!" Но они решили добежать за 30 минут — ну значит и получите граблями! Это наказание ждёт любого, кто делает "побырому".

S>... стоимость добавления любой мелочи зависит не столько от её размера в коде, сколько от её влияния на экосистему шарпа в целом.


Не спорю. Но это не повод считать КАЖДУЮ "мелочь" — каким-то охренительным проектом! Более того: если что-то кажется мелочью, скорее всего и решение не должно быть (в идеале) сложным.
Вот те же замусоленные "инициализаторы автопропертей" (уж извини, пример хороший ) — почему добавление "= expression;" должно вызывать какие-то немыслимые сложности? Чувак, это просто дополнение к синтаксису! Даже семантика не меняется! А значит, твой компилятор должен быть построен так, что расширение "обычного автопроперти" до "инициализируемого" должно достигаться чуть ли не единственной правкой EBNF! Звучит слишком просто, но это так.

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


гы Нет, не передёргивай. Я просил не C# 6.0, а Рослин! Он ОБЯЗАН был быть! Не с первой, так со второй версии. Ну как вообще можно было избежать Рослина, ты подумай? Ведь кто-то же ходил по Микрософту с умным видом, рассказывал боссу про студию, её расширение, единый механизм синтаксиса... постой, синтаксис? А в компиляторе разве не он же проверяется? Вот, ***ть, КАКОЕ СОВПАДЕНИЕ! Очевидно, что кто-то это всё знал, но почему-то команды всё-равно были разные (будто на разных планетах — это ж надо так засрать менеджмент!) и одна пилила то же, что и другая. Гениально...

S>Смотри как парадоксально. Есть компании, которые....


Про коммерцию не надо — она не подвержена математической логике, как непостижимо то, что ГовноDOS вдруг выйграл у CP/M. Это просто грязная политика
Re[21]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 07.08.14 20:17
Оценка: 37 (3)
VD>Сейчас кода у вас есть Рослин было бы разумно начать работу над алгеброическими типами и паттерн-матчингом.

N>Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.


Черновик дизайна
Обсуждение на CodePlex
Публично доступного кода пока нет, ожидается через пару недель
Re: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.06.14 09:58
Оценка: 35 (2) +1
Здравствуйте, Sinix, Вы писали:

S>Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS


Проверку, на свой страх и риск,можно отключить, но 145 студия что то ломает внутри 13. Впрочем, это лечится сносом 14 и переустановкой 13.

S>Из того, что точно будет интересно пощупать — интегрированный в VS roslyn compiler + c# 6 со всеми плюшками типа someVal?.ToString() ?? "".


Только со стороны студии поддержки никакой, увы. Все новые конструкции отображаются как ошибки и ломают интеллисенс. И надо ручками задать <LangVersion>Experimental</LangVersion> в файле проекта.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[8]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 22.06.14 02:27
Оценка: 1 (1) +2
Здравствуйте, btn1, Вы писали:

B>Вот те же замусоленные "инициализаторы автопропертей" (уж извини, пример хороший ) — почему добавление "= expression;" должно вызывать какие-то немыслимые сложности? Чувак, это просто дополнение к синтаксису! Даже семантика не меняется! А значит, твой компилятор должен быть построен так, что расширение "обычного автопроперти" до "инициализируемого" должно достигаться чуть ли не единственной правкой EBNF! Звучит слишком просто, но это так.


То есть ты считаешь, что в существующих инициализаторах полей может быть только expression?
А инициализатор свойства может использовать те же синтаксические узлы, как и инициализатор поля, потому что синтаксически совершенно ничем не отличается?
А когда эти инициализаторы должны выполняться — до тела конструктора или после? до инициализаторов в базовом классе или после? до конструктора базового класса или после?
Нужно ли выполнять инициализатор свойства в базовом классе, если оно virtual и имеет override в производном классе с другим инициализатором?
Компилятор должен быть спроектирован так, чтобы автоматически правильно ответить на все эти вопросы после правки EBNF, правда? И заодно сам сочинить сообщения об ошибках для всех некорректных случаев? Или достаточно сказать "ваша программа не соответствует EBNF"?
Re[3]: [Ann] VS14 Сtp0
От: btn1  
Дата: 04.06.14 14:46
Оценка: -3
Здравствуйте, Sinix, Вы писали:

S>String interpolation скорее заменяет string.Format, да и то частично. К выводу строк оно никакого отношения не имеет.


Пардон, описался. Но ты понимаешь, что я имел ввиду.

S>А почитай обсуждение.


Читал. Много думал — сколько же нужно ПИНКОВ ПОД ЗАД, чтобы эти тюлени хоть что-то написали!

S> До рослина никто бы этим не занимался (по понятным причинам)


?? Это по каким ещё причинам IS(interpolates strings) стали вдруг уникальной фишкой Рослина?? Это же обычный синтаксический сахарок!

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


Ну как бы фича-то ни бог весть какая уникальная и "свежепридуманная" — Руби с Перлом используют её уже как сто лет!

S>Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:


Там нечего "ломать" — надо просто ввести новую функциональность. По вопросам охотно отвечу, но сразу сделаю Главное Замечание: IS — это не замена string.Format! Это просто фича "быстро и удобно вставить значение в строку" — с наиболее употребимыми умолчаниями и как можно более простым чтением. Соответственно, сразу отпадают неуместные вопросы:

S>* Допустимы ли выражения внутри "{Name}", или только идентификаторы? Вызов методов?

S>* Какая культура должна быть по умолчанию? Нужен ли способ явно указать культуру?
S>* Добавлять ли синтаксис форматирования от string.Format() ( $"{time:0.0##} second(s) left!")? Кидать ли ошибки при неверном синтаксисе?
S>* Поддерживать ли этот формат в [DebuggerDisplay]? API для подобных атрибутов?

Т.е. мы вводим фичу только для самых употребимых случаев: есть строка, в неё нужно вставить значение.
Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access). Понравится — оставят, допилят. Покажется неудобным — да ради бога, заменим, но сама фича должна быть доступна уже сейчас!

S>* Как объявлять такие строки — с префиксом $"Hi, {Name}!" или через "Hi, \{Name\}!"?


Вариант с \{} — сразу в топку как неудобочитаемый. Вопрос только, а зачем вообще нужен префикс?? Что, старые строки нельзя "рассматривать по-новому"? Старый код — для него всегда можно ввести warning: "ваша строка похожа на новую фичу". Наконец, был озвучен не самый плохой вариант с "ёлочками": « и » (и тогда отпадает конфуз с verbatim: @«»)
Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать.
На данный момент никаких проблем не будет, если тупо ввести $ в существующие строки — хочешь — включай фичу, не хочешь (для легаси кода) — не включай.

S>* Нужна ли возможность заменить interpolator (штуку, которая будет раскрывать выражения в {})? Если да — какие сценарии надо учитывать — razor, sql-форматтеры, биндинг, ещё что-нибудь?


Не нужно. Это будет приятная фича языка для простой вставки значений, всё что свыше — overengineering.

S>* Нужна ли функция обратного парсинга строки?


Не понимаю терминологии. О чём речь?

S>* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic?


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

S>* Как насчёт динамических строк, например, строк из ресурсных сборок?


Ввести системную функцию string.Interpolate(MyStringFromResource). Это как опция, я напоминаю Главное Замечание: нужна простая функция вставки значения. Ни интерпретатор строк, ни конструктор гипертекста, ни замена всему живому в строках, а просто $name — получи значение name.

S>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай


Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.
Re[9]: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 19:43
Оценка: -3
Здравствуйте, QrystaL, Вы писали:

QL>Сколько желчи


Желчь?? В простой констатации факта, что Win8 — это epic fail? Ну извини, я не знаю, какие ещё слова подобрать к полному провалу. Может, "альтернативный успех"?
Re[9]: [Ann] VS14 Сtp0
От: btn1  
Дата: 21.06.14 13:07
Оценка: -1 :))
Здравствуйте, Sinix, Вы писали:

S>Перечитай предыдущий пост, там смысл по-моему очевиден: MS не получает денег напрямую с новых фич, максимум пользы от них — приманить новых клиентов. Куда важнее не потерять старых.


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

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


Ну да. Т.е. по-твоему, я один хочу interpolating strings, а счётчик голосовалок я сам накрутил! Глупо рассуждаешь. Не МНЕ нравятся, а МНОГИМ нравятся — я ещё не видел людей, которые бы корчились на облегчение их жизни.
Строки не сделаны и это плохо, потому что сама фича — грошовая и хоть в каком-то виде (тем более для CTP!) могла быть запилена.

S> Надо заметить, конструктива топику это не добавляет


А что ты-то сказал конструктивного, товарищ? Сыпешь техническими доказательствами? Точно так же фонтанируешь идеями как мы все — не надо дартаньянства, ага?

S>Офф: тем не менее, MS очень внимательно стала относиться к поддержке со стороны community.


Не более, чем всегда. От ухода одного Баллмера внутрикорпоративный мир мелкософта не поменялся — он инертен.

S>>>... добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка.

B>>А как тут измеряется ВЫЙГРЫШ?

S>Офф 2, grammarnazi, не вам лично: выИгрыш Мозайка йз войнов андройда блйн!

S>Понятно, что опечатка по Фрейду, но достало уже.

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

S> Проиграть можно очень легко: запороть новой фичей возможность расширения языка


Конкретно по строкам — что они там "запарывают"? Почему на тривиальную проблему надо смотреть как на какое-то вселенское изменение??
Вот были автоинициализаторы переменных и полей: int i = 2; А вот для пропертей этого не сделали! Это УЖЕ концептуальный перекос, хотя 1) фичу для полей всё-таки запилили 2) теперь это делают и для пропертей(!!!) — зачем тогда умничать? К чему все эти рассусоливания на пустом месте, если сами же налажали до этого? НЕПОСЛЕДОВАТЕЛЬНОСТЬ — вот признак лажовенькой команды. Либо все фичи должны "академически" проверяться, доказываться и т.п., либо нечего выпежониваться и запиливать полезняшки по мере более-менее готовому проекту.


B>>Фичи можно как-то сравнить по полезности, но извини, что-то я не припомню никаких революций в мире C#, сильно облегчающих мне жизнь. Зато кучи маленьких, но необходимых вещей так и померли под отговорками тех, кто говнокодил до "эпохи Рослина".

S>Тоже писалось выше. Выбор у разработчиков до недавнего времени был не "добавим финтифлюшку/не добавим" а "успеваем выпустить всё, что обязательно должно быть к текущей итерации/не успеваем".

Я про это и написал: революций — не было, но тем не менее, время куда-то профукано — НА ЧТО? Наопмню, для начала — первый "цэшарп" был сделан в 1992 году. Ничего так срок? 12 лет, 220 будней, по 8 часов "работы", а на выходе — мышь. И посмотри на D — язык, который пилят от силы человек пять! Да он уже сейчас по возможностям заткнул C# в нехорошее место. Очевидно, что шарповоды больше тратят время на кофе и квадратики — это ж не мешки ворочать!


B>>Ну вот, скажем, инициализация автопроперти — что, дюже прорывная фича?

S>На мой взгляд, на практике полезна разве что для скриптов и прочих поделок.

Это очень частный и прямо скажем — недальновидный, слабопрофессиональный взгляд — простительно, но только для вас лично. Команда же C# эту фичу считает полезной и БУДЕТ делать ввиду очевидной полезности для тысяч прогеров — даже не понимаю, каким боком тут какие-то "скрипты" — вы C# не компилируете что ли?

S> Добавляем валидацию параметров в конструктор (или вы в каждый класс что попало суёте?) и всё удобство моментально идёт лесом.


И как эта валидация пересекается с инициализацией?? Можно пример кода для понятности?

S>Но ок — что надо было перекинуть на другой релиз ради набора подобных мегафич? Генерики? linq? await? dlr?


Покажите ВЕСЬ _внутренний_ набор ToDo команды C# — я расскажу. А жонглировать мегафичами не надо, не ими одними занимались шарпопилы.


S>Ненависть-скандалы-интриги-расследования — эт в flame.comp и в прочие мусорные ветки плиз


Без тебя разберусь, кто интриги, а кто просто жадный буржуй. То, что КОММЕРЧЕСКАЯ фирма жмотит деньги на хороших специалистов — увы, ТОЖЕ необходимая вещь для выяснения правды.

S> Я хочу здесь и сейчас, пусть ценой неудобств, возможность _новый_ код писать на _новом_ языке. Повторюсь: "мэйнстрим" никто никуда не тащит, пусть сидит на FW 2.0 и лелеет свои мегабайты суперкода.

S>[/q]
S>и, когда они делают ровно то, что просил, возмущаешься
S>

S>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8?

S>(если что, проблема скорее всего в win7 без обновлений. У ранних ctp vs2013 те же проблемы были).

У тебя по логике "тройка" что ли? Где связь между ограничением платформы VS и просьбой запилить элементарные строки, которые вообще никакого отношения к Windows не имеют? Сходи на лекции что ли, чем моё время тратить на трололо.
Re[9]: [Ann] VS14 Сtp0
От: kleng  
Дата: 23.06.14 15:18
Оценка: -2 :)
Здравствуйте, Sinix, Вы писали:

S>Из "Я видел косяки в A" никак не следует "B и C — отстой", это ошибка в логике.


        enum Foo { Bar1 = 0, Bar2 }

        static void Main(string[] args)
        {
            var foo = (Foo)100; // WTF???
        }


Глядя на такие фокусы, мне с трудом верится в высокий профессиональный уровень разработчиков компилятора.
Re[10]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 22.06.14 02:55
Оценка: 23 (2)
Здравствуйте, hi_octane, Вы писали:

_>То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями. Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался?


На всякий случай — это не "забыли" или "не догадались" сделать. Возможная расширяемость, как на стороне потребителя (кодогенерация для await), так и на стороне производителя (кодогенерация для async методов) активно обсуждалась и прототипировалась. Рассматривались, в том числе, возможность использования await внутри методов-итераторов и добавление интерфейсов IAsyncEnumerable/Enumerator с асинхронным методом MoveNext. В конечном счёте, после оценок стоимость/полезность, было решено остановиться на расширяемости только на стороне потребителя (кастомный awaiter). Это то, что могло быть сделано в намеченные сроки с достаточным качеством, и покрыть значительную часть спроса пользователей. Возможные дальнейшие улучшения были отложены на следующие версии. Например, await в catch/finally блоках был позже реализован в Roslyn (что потребовало довольно хитрой кодогенерации).
Re[11]: [Ann] VS14 Сtp0
От: hi_octane Беларусь  
Дата: 06.06.14 16:38
Оценка: 20 (1) +1
S>Ну, могу или там плюсик убрать или тут извиниться. Выбирай


S>Если серьёзно, на практике всё не так, как в теории. Внезапно оказывается, что "хардкод await на Task" ничему не мешает. Точно так же, как хардкод yield return на IEnumerable<>.


Это если кроме "запустил и забыл" ничего не надо, тогда не мешает. А если хочется за задачей и всеми задачами которые она порождает протащить состояние, какую-то информацию для собственного scheduler'a, да даже, например, программер-френдли имя самой задачи и её родительской задачи + время старта каждой для логгирования — приехали.

S>При желании хардкод заменяется на IAsyncStateMachine и IAsyncMethodBuilder, т.е. в будущем никто не запретит добавить в INotifyCompletion

S>
S>IAsyncMethodBuilder<IAwaitable<T>> GetMethodBuilder();
S>

S> и извращаться как заблагорассудится. На практике смысла в этом не больше, чем в замене итератора для yield return. Посмотри внутренности дефолтного AsyncMethodBuilder, там весь функционал по большому счёту сводится к m_Task.SetResult.

Ну если мне дадут в Task'х решения задач вроде этих
Автор: hi_octane
Дата: 12.10.12
, или слепить свой аналог ThreadLocal
Автор: hi_octane
Дата: 03.12.12
(ну только TaskLocal), то да, польза от самописных тасков для меня будет сомнительна. Но всегда найдётся человек которому мало решений моих задач, свои решать надо, и уже этот человек придёт на форум и будет ругаться что про него забыли

S>Не, при большом желании можно переписать таск с 0 (где-то пара человекомесяцев минимум), но зачем — мне решительно непонятно. Разве что чтобы возмущаться "опять используют велосипед вместо готового решения"


Да мне бы по-простому — отнаследоваться, и протаскивать буквально пару полей из таска в таск где это надо, и не протаскивать там где не надо. Человеко-дни. Ну может ещё одна-две человеко-ночи, чисто из-за того что с отладкой этого дела сложности могут быть

S>Потому же, почему нельзя вернуть IMyEnumerable<T> из кастомного итератора — во, первых, фичу никто не спроектировал, не закодил, не протестировал и не отправил в продакшн. Во-вторых, идея на корню рубится типовыми сценариями использования. Для IEnumerable это linq, для async — await. Как через них будешь свой чудо-тип протаскивать?

Против IEnumerable почти ничего не имею. А чудо-Task вот надо


_>>А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции.

S>Ну ок, можно попросить чтоб в следующей версии добавился
S>
S>ILockable { bool TryEnter(); Exit(); }
S>

S>только нужно ещё обосновать, зачем это щастье надо. Потому что внезапно выяснится, что на практике в rwlock надо передавать таймаут и/или CancellationToken и что на самом деле пользователей интересует совсем другое.
ну сразу хотелось бы иметь Task.CurrentTask.CancellationToken (был бы MyTask — легко), да и без него lock(ReaderWriterLock.Read(Timeout)) и т.п., при наличии ILockable вопрос решается тысячей способов. Без него — try/catch/finally и побежали — т.е. никак.

S>Понимаете, вы смотрите на отдельную фичу и она вам так нравится, что вы забываете про все остальные задачи-проблемы, пока нужное не появится в языке. И тогда внезапно оказывается, что нужно было сделать не то, что клиент просил, а предоставить инфраструктуру для решения целого класса проблем, которые прятались за этой недостающей фичей. Вон btn1 выше в одном посте требует "никакого легаси, только вперёд, только хардкор" и следом удивляется "как это без поддержки win7???". Бойтесь желаний, они сбываются


Так и я о чём. Вместо размножения ускоспециализированных фич — дайте инфраструктуру и самую дубовую реализацию построенную на ней (без всяких internal/private для себя, и одного virtual метода для всех). А мы уж дальше сами. Например те же TaskScheduler'ы — вполне себе соответствуют этой парадигме. И вот уже пожалуйста — 20 видов типовых Scheduler'ов искаропки. Не сравнить с ThreadPool три метода на все случаи жизни, и с таймаутами вопрос решён предельно чётко
Re[8]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 06.06.14 07:50
Оценка: 16 (1) +1
Здравствуйте, btn1, Вы писали:

S>>Всё просто — MS не получает денег за добавление новых фич.

B>Если говорить о деньгах, получается мелкософт прямо облизывает своих клиентов "какие фичи вы хотите в следующем релизе? Ведь вы заплатили за студию — имеете право!" — так штоле?

А вот не надо выцеплять фразы из контекста напрямую и додумывать
Перечитай предыдущий пост, там смысл по-моему очевиден: MS не получает денег напрямую с новых фич, максимум пользы от них — приманить новых клиентов. Куда важнее не потерять старых.

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

Офф: тем не менее, MS очень внимательно стала относиться к поддержке со стороны community. От голосовалок на uservoice и до принятия сторонних коммитов в код asp.net/ef.



S>>... добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка.

B>А как тут измеряется ВЫЙГРЫШ? Количество эндорфина на куб.см. мозга юзера? Количество продаж студии? Громкость хлопков при анонсе фичи? Я не понимаю, как можно "проигрывать" там, где ты тупо делаешь язык лучше!

Офф 2, grammarnazi, не вам лично: выИгрыш Мозайка йз войнов андройда блйн!
Понятно, что опечатка по Фрейду, но достало уже. Хуже чем "ться", там хоть понятно откуда ошибка. А вот как можно засунуть й куда не лезет — эт для меня загадка

Уже писал выше, давай ещё раз. Проиграть можно очень легко: запороть новой фичей возможность расширения языка, сделать фичу так, что её легче использовать неправильно, чем правильно, поломать совместимость. Пример врождённых косяков есть у любого языка, c# не исключение. Другое дело, что доля этих косяков — 0.01, а не 200% (да-да, js, я говорю про тебя!)


B>Фичи можно как-то сравнить по полезности, но извини, что-то я не припомню никаких революций в мире C#, сильно облегчающих мне жизнь. Зато кучи маленьких, но необходимых вещей так и померли под отговорками тех, кто говнокодил до "эпохи Рослина".

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

B>Ну вот, скажем, инициализация автопроперти — что, дюже прорывная фича?

На мой взгляд, на практике полезна разве что для скриптов и прочих поделок. Добавляем валидацию параметров в конструктор (или вы в каждый класс что попало суёте?) и всё удобство моментально идёт лесом.

Но ок — что надо было перекинуть на другой релиз ради набора подобных мегафич? Генерики? linq? await? dlr? Или как всегда, должна быть магия и все фичи должны добавляться бесплатно?



B>...и правильно делают! Потому что деньги — не вопрос, специалистов — море, но M$ всё равно продолжает "кидать" юзеров. Нет времени? Ах вы, ***, бедненькие, в поту и крови пашете под палящим солнцем, жену-детей не видели пол-года! Так штоле? Нет. Сидят, крутят свои ж**ы в креслах, пьют кофе, рассуждают о выходных — обычная офисная работа! Нет рук? Я тя умоляю, НАЙМИ ЕЩЁ ЛЮДЕЙ, но только не индусов! Пройдёт пол-года и каждый член команды будет с лёгкостью факира выкатывать фичи. Или опять... "жадность"? Вот то-то же!


Ненависть-скандалы-интриги-расследования — эт в flame.comp и в прочие мусорные ветки плиз, промахнулись окошком Ещё, очень советую поработать хоть раз в жизни хотя бы с мааленьким коллективом на 15-20 человек, фантазии про "девять женщин выносят ребёнка за месяц" сразу пропадут.

B>Про коммерцию не надо — она не подвержена математической логике, как непостижимо то, что ГовноDOS вдруг выйграл у CP/M. Это просто грязная политика


Ну, это эльфизм. Игнорировать реальность не надо, больно бьёт по носу. Ты сам выше привёл такой пример: одновременно требуешь от MS

Я хочу здесь и сейчас, пусть ценой неудобств, возможность _новый_ код писать на _новом_ языке. Повторюсь: "мэйнстрим" никто никуда не тащит, пусть сидит на FW 2.0 и лелеет свои мегабайты суперкода.

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

каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8?

(если что, проблема скорее всего в win7 без обновлений. У ранних ctp vs2013 те же проблемы были).
Re[4]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 05.06.14 11:49
Оценка: 10 (1) -1
Здравствуйте, hi_octane, Вы писали:

S>>Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:

S>>ну и тд и тп.

_>4 года назад мы спорили о микроменеджменте фич языка
Автор: hi_octane
Дата: 03.11.10
. Эта штука ущербна по определению. И Эрик Липперт уже ушёл, а ничего в головах людей работающих над компилятором C# не изменилось


Ну вот смотри. Ты автор языка, которым пользуются дофигищща разработчиков. Вот тут не особо скромничая вообще загнули про "C#, the language used by an estimated six million developers worldwide", но ок, сократим на порядок, до 600k.

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

Также из этого следует, что новые фичи тоже нельзя добавлять "просто так", они могут помешать развитию языка через итерацию-другую. Вопрос про custom string interpolator как раз из этой группы.

Оценить, насколько эта стратегия выигрышная, очень легко.

2008:
Client (Windows Operating System)
Revenue: $16,865,000,000
Operating Income: $13,052,000,000
...
Server and Tools (Windows Server, Microsoft SQL Server, Visual Studio)
Revenue: $13,170,000,000
Operating Income: $4,593,000,000


2013:
Windows (including Surface tablets and other hardware)
Revenue: $19,239,000,000 (+5%)
Operating Income: $9,504,000,000 (-18%)
...
Server and Tools (Windows Server, Microsoft SQL, Visual Studio)
Revenue: $20,281,000,000 (+9%)
Operating Income: $8,164,000,000 (+13%)

(c)
Прибыль от Operating System как бы намекает: всё ок, можно ломать дальше


Так вот, тебе нужно добавить "маленькую" фичу, которая по большому счёту никакой особой пользы не несёт, зато "как в %подставить_язык%!!!".

Так вот, вариант
_>добавить Compile-Time String Formatter класс, использующих API Roslyn и контекст где описана строка — он сам построит дерево вызовов ToString для аргументов и подсунет текущую культуру, текущий форматтер и т.п. Плюс открытая реализация чтобы его можно было подменить/расширить, и тогда базовый вариант будет доступен всем, а на кодеплексе сами размножатся самые нетривиальные форматтеры, от поддерживающих абсолютно все фичи которые там обсуждаются + те до которых мы никогда не додумаемся.

— это неправильный ответ. Потому что всего-то надо:

* добавить AOP-style расширения шарпа, обеспечить их поддержку вместе с dynamic/expression trees.
* отполировать API рослина до пригодности для массового написания расширений (на сегодня это мяхко говоря не так).
* объяснить 600k клиентам, что если им что-то не нравится, они всегда могут сами допилить язык до нужного им состояния.

Сорри, но изначально roslyn team всего-то собиралась транслировать $"Hello, {world}!" в string.Format("Hello, {0}!", world). И даже для такой мелочи нужно рассмотреть тонну вопросов, т.к. потом решение поменять будет слегка поздновато.

С вашим вариантом фичу надо ждать ближе к седьмому шарпу
Re[7]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 21:11
Оценка: 2 (2)
Здравствуйте, nikov, Вы писали:

N>Прототипы писали, и там далеко не 20 строк.


Не 20. Но и не года несустветные. За месяц запилить можно без проблем.

N>Начнём с того, что строковые литералы перестают быть монолитными токенами, и должны теперь содержать синтаксические узлы, которые могут представлять имя переменной (константы, поля, свойства...). Эти синтаксические узлы могут иметь собственные предупреждения/ошибки, которые не относятся к строке в целом (использование переменной до присваивания, доступ к экземплярному члену из статического контекста, использование Obsolete члена...). Также другие фичи, как, например, Find All References, Rename refactoring, Extract Method refactoring должны знать о наличии этого узла, и правильно его обрабатывать.


Какие-то отмазки. Ну, да содержат, должны и т.п. Что в этом страшного то? Берем строку, парсим. Получаем отрезки строк и отрезки кода. Трансформируем выражение (генерируем код) и получаем окончательный вариант который и подвергаем типизации. все описанное выше получается в автомате.

N>Ввиду того, что такие строки могут перестать быть constant expressions (ещё вопрос: может быть, они должны оставаться constant expresions, если все interpolated expressions — константы?), надо исправлять код, работающий с constant expressions, и с другими категориями "почти константных" выражений, как, например, аргументы атрибутов.


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

N>Каким образом значение interpolated expression должно преобразовываться в строку? С помощью вызова метода .ToString()? А если там null, то должно быть исключение, или пустая строка, или специальная строка "<null>"?


Ну, у тебя то доступ к немерлу есть. Погляди как у нас сделано. Да и спросить на форуме можно, что народ хочет.
Нулы, конечно же, нужно превращать в пустые строки. Исключения при работе со строками никому не нужны.
Если кому-то понадобится специальная обработка, он преобразование в функцию завернет.

N> А если объект скрывает виртуальный метод .ToString(), унаследованный от object, с помощью другого метода или свойства? Должна ли это быть ошибка, или мы должны попытаться вызвать этот метод или свойство (надеясь, что оно возвращает подходящий тип), или мы должны всё-таки вызвать скрытый базовый метод? А если intepolated expression имеет тип dynamic, должен ли это быть динамический вызов метода .ToString()?


Это не суть важно. Если кому-то не понравится ваше поведение он всегда его сможет подменить переводя объект в строку самостоятельно. Надо выбрать одну стратегию и придерживаться ее везде и всегда. Или тупо использовать паттерн .ToString() (перекрыт не перекрыт — не важно) или всегда кастить к обжекту и звать виртуальный. Главное чтобы не было и то, и то. Я оборачивал сплайсы в вызовы System.Convert.ToString(). Это упрощало реализацию и давало однообразную логику.

N>А затем, должен ли это быть динамический вызов оператора + в выражении "..." + d.ToString() + "..."? А окончательный тип выражения должен быть тоже dynamic, или мы должны динамически вызвать (возможно, user-defined) оператор приведения к string?


Все что внутри сплайса должно вычисляться по обычной логике выражений. Далее, к результату, должен применяться единый подход преобразования. Люди должны иметь понятный алгоритм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] VS14 Сtp0
От: hi_octane Беларусь  
Дата: 05.06.14 12:28
Оценка: 1 (1) +1
S>Сорри, но изначально roslyn team всего-то собиралась транслировать $"Hello, {world}!" в string.Format("Hello, {0}!", world). И даже для такой мелочи нужно рассмотреть тонну вопросов, т.к. потом решение поменять будет слегка поздновато.

Дык именно из-за того что изначально рассматриваются мини-фичи поштучно именно так как ты описал, и реализуются каждая отдельно, у команды C# есть наверное уже 6-й несовместимый способ описания/генерации C#-кода: expression trees, та модель которая под dynamic, почти уже умерший CodeDom, их внутреннее представление в старых компиляторах C#, их VsCodeModel представление для автокомплита/рефакторинга в студии до Roslyn, и, наконец, Roslyn. Думаю я ещё пару упустил просто потому что не инсайдер

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

Эти бы ресурсы да что б не "квадратное катить, круглое тащить", и мы бы уже давно имели:

S>* добавить AOP-style расширения шарпа, обеспечить их поддержку вместе с dynamic/expression trees.

S>* отполировать API рослина до пригодности для массового написания расширений (на сегодня это мяхко говоря не так).

И вот это:

S>* объяснить 600k клиентам, что если им что-то не нравится, они всегда могут сами допилить язык до нужного им состояния.


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

S>С вашим вариантом фичу надо ждать ближе к седьмому шарпу

Я верю что к тому времени уже Nitra выйдет
Re[4]: [Ann] VS14 Сtp0
От: fddima  
Дата: 05.06.14 21:35
Оценка: 1 (1) +1
Здравствуйте, hi_octane, Вы писали:

_>Поднимать вопрос за вопросом можно до бесконечности, но если отойти на шаг выше, и добавить добавить Compile-Time String Formatter класс, использующих API Roslyn и контекст где описана строка — он сам построит дерево вызовов ToString для аргументов и подсунет текущую культуру, текущий форматтер и т.п. Плюс открытая реализация чтобы его можно было подменить/расширить, и тогда базовый вариант будет доступен всем, а на кодеплексе сами размножатся самые нетривиальные форматтеры, от поддерживающих абсолютно все фичи которые там обсуждаются + те до которых мы никогда не додумаемся.

Мы все работаем на разными вещами, но вот выделенное — меня так задолбало. Да не нужна культура программистам. Там где она реально нужна — они об это осведомлены. У вас возможно другой опыт. Просто это всё ведет к жётским траблам, когда софт разрабатывается "тут", а используется "там". Как делать, так, что бы не было проблем — понятно. Нафиг нужна дефолтная культура — мне вот — ниразу не очевидно. Впрочем, опять повторюсь, возможно, разный софт.
Re[8]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 22.06.14 19:13
Оценка: 1 (1) +1
Здравствуйте, btn1, Вы писали:

B>Я не понимаю, как можно "проигрывать" там, где ты тупо делаешь язык лучше!


Очень просто. Можно случайно выбрать неудачный синтаксис для полезной (но малополезной) фичи так, что это заблокирует или сильно затруднит добавление очень полезной фичи в наиболее удобном и естественном синтаксическом виде в следующей версии.
Re[10]: [Ann] VS14 Сtp0
От: DreamMaker  
Дата: 06.06.14 14:14
Оценка: +2
Здравствуйте, btn1, Вы писали:

B>Желчь?? В простой констатации факта, что Win8 — это epic fail? Ну извини, я не знаю, какие ещё слова подобрать к [url=www.google.co.za/search?

hl=en&q=Windows+8+провалилась"]полному провалу[/url]. Может, "альтернативный успех"?

интересно, а что доказывает ссылка на поиск в гугле "Windows 8 провалилась?". Рез-ов по этому запросу немного больше чем по запросам "пришельцы похищают людей", но меньше чем по "25 кадр" и намного меньше чем по "чупакабра" и "рак мозга от компьютера"

может лучше на финансовые отчеты посмотреть? или на график стоимости MSFT? (посмотрите, кстати).
In P=NP we trust.
Re[2]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 22.06.14 18:02
Оценка: +2
Здравствуйте, btn1, Вы писали:

B>проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")


Надо внимательнее читать сопроводительный текст. Выставлять не 6.0, а Experimental.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[5]: [Ann] VS14 Сtp0
От: Аноним  
Дата: 23.06.14 11:41
Оценка: :))
Здравствуйте, fddima, Вы писали:

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


F> Да не нужна культура программистам. Там где она реально нужна — они об это осведомлены.

F> не нужна культура программистам.

По форуму это видно, ага.
Re[11]: [Ann] VS14 Сtp0
От: kleng  
Дата: 23.06.14 16:23
Оценка: -2
Здравствуйте, nikov, Вы писали:

N>Ты читал спецификацию C#, спецификацию CLI? Они требуют, чтобы енумы работали именно так.


Ну если нелепость внесли в спецификацию, то это конечно уже не нелепость.
Re[23]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 14.08.14 23:15
Оценка: 30 (1)
Здравствуйте, Qodomoc, Вы писали:

Q>А дженерики можно будет использовать?


В текущем дизайне generic типы ведут себя совершенно одинаково с не-generic. Никакие сценарии для них не запрещены, но и никаких специфических возможностей (наподобие использования existential типов в pattern matching) не предусмотрено. Но если есть какие-то потребности, было бы интересно послушать. Интересует какой-то конкретный сценарий?
Re[5]: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 22:02
Оценка: 21 (1)
Здравствуйте, fddima, Вы писали:

F> Мы все работаем на разными вещами, но вот выделенное — меня так задолбало. Да не нужна культура программистам.


+1. Ни в одной конторе, где работал, народ даже не думает о каких то Right-to-left, decimal point/comma и т.п. — софт шёл исключительно на англоязычный рынок, везде "десятичная точка", а с датами вообще всё просто — хранят как год-месяц-день-и-т-д, а выводят дефолтовым (читай, системным) способом.
Но не суть, просто не всем дано осознать совершенство простоты Interpolation strings — это хорошая лакмусовая бумажка на overengineering — проверка на то, что когда ты человеку дашь простую задачу на неделю, он вернётся через месяц (с опозданием на три недели) с сотней классов и парой самописных библиотек, решающих 10 задач, из которых 9 никогда не понадобятся.
Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.14 16:06
Оценка: 18 (1)
Здравствуйте, nikov, Вы писали:

N>Кстати, Nemerle позволяет использовать строковые литералы внутри interpolated выражений?


Да. Но не все так просто.

Вложить в "" другую "", по понятным соображениям нельзя. У нас есть рекурсивная строка <# #>. У нее никаких проблем нет. В нее можно и "" вкладывать и саму же <# #> (так как она рекурсивна).

Вот первое попавшееся применение:
public DebugView : string
{
  get { $<#..$(Parents; "\r\n"; p => $"$p        $(p.GetType().Name)")#> }

Сплайс ..$ раскрывает список (любой энумератор). Его грамматика (в стиле найтры) такова:
syntax ListSlice = ".." "$" SliceBody;
syntax SliceBody
{
  | Identifier
  | "(" PExpr SeparatorAndConverter? ")"
}
syntax SeparatorAndConverter = ";" PExpr Converter?;
syntax Converter = ";" PExpr;


В Separator ожидается выражение возвращающее строку. Она используется как разделитель списка. По умолчанию используется ", ".
В Converter ожидается выражение функционального типа принимающего элемент списка и возвращающего строку. По умолчанию System.Convert().
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 10:51
Оценка: 15 (1)
Здравствуйте, gandjustas, Вы писали:

B>>Это не самый главный критерий в языке

G>Увы, для мейнстримного языка — главный, как бы ни казалось обратное.

Я согласен, что _желательно_ поддерживать совместимость. Но разве этот "мэйнстрим" кто-то тащит использовать новый язык??
Да и что там "ломать"? Интерполяция строк — это же не замена круглых скобок на квадратные! Это те же строки, но с дополнительным парсингом доллара (ну, если принять синтаксис "name = $name").

B>>который сначала тупо переписали с Жабы, потом допилили, потом ещё допилили, а затем получился язык, который 100% не пойдёт на C# 1.0;

G>Это ты к чему написал? Сейчас оооочень много кода для C# 1.0 компилируется последней версией языка, не 100% но более 99% точно.

Это несколько странный выпад я его недообъяснил: C# 1.0 — это, можно сказать, "чуть улучшеная Жаба". C# 5.0 — это почти идеал, на котором легко и приятно писать и который содержит тучу улучшений. Но ведь никто же не сидит на C# 1.0, потому что его "интыпрайзный код" (написанный теми же студентами) так дорог? Если можно — индустрия движется вперёд, использует новые фичи, парадигмы и т.п. В этом свете я бы предпочёл слегка перелопатить код и влиться в авангард, чем объяснять каждому новичку "ну знаешь, мы вот тут такие хитрые строки используем, поэтому мы сидим на позапрошлом поколении компилятора, короче привыкай!". Ну не тупость? Вы так говорите о "несовместимости", будто эти, мать их, "интерполяционные строки" прям переворачивают код с ног на голову! Да ничего подобного — просто лишний синтаксический сахар.

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

G>У C# получается, и стратегия такова что и будет получаться.

Ерунда. "Получается" только потому, что почти нихрена не делается (я имею ввиду радикальные улучшения). Скажем, инициализация проперти
int i {get;set;} = 7;
— сколько лет понадобилось с момента создания самих пропертей, чтобы наконец понять — блин, ведь проперть используется почти так же, как и поле — почему б и инициализацию не сделать такой же удобной?! Сейчас это есть, но на календаре прошло 10 лет... не многовато ли мы платим за "совместимость"? Или ваш дедушка — Дункан Маклауд? Я хочу здесь и сейчас, пусть ценой неудобств, возможность _новый_ код писать на _новом_ языке. Повторюсь: "мэйнстрим" никто никуда не тащит, пусть сидит на FW 2.0 и лелеет свои мегабайты суперкода.


B>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).

G>Увы в C# такое невозможно.

Ха Что зн "невозможно", когда в сишарпе же это и сделано!! Посмотри директиву LangVersion в csproj — там тупо указывается "используем экспериментальную возможность"! Чем IS хуже?


B>>Кто хочет — пусть пользуются новыми фичами. У кого код ломается — пусть сидит на C# 5.0; Но сидеть на старье только потому, что кто-то там себе в строках забубенил доллар — это тупость.

G>Фактически это означает что 90% будут сидеть на C# 5.0

Откуда цифры? Чуров насчитал? Не надо заниматься сочинительством, ведь очевидно: "строк с долларом и последущим именем" ничтожно мало, это не самый популярный вид строк! А вот "плюшка" — популярная, ею обозначают места параметров для MS SQL.

G>, это затормозит развитие фреймворков, что в свою очередь уронит продажи Visual Studio и серверных продуктов.


Спасибо, поржал. А в отделе M$ маркетинга не догадались, что VS2014, ставящаяся ТОЛЬКО на Win8 вообще УБЬЁТ ВСЕ ПРОДАЖИ?

G>С VM проще, ничего не мешает...


Ключевое слово — "непродуманность". Как писали VM, так же писали и язык, что "возврат нескольких значений" для M$ до сих пор rocket science. В этом свете цепляться за совместимость — разве только ради продаж, вы правы. Но мы же не маркетоиды, мы как бы о языках говорим!

G>Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6


Это ни о чём не говорит, вы же знаете какой маразм бывает в конторах: работает ядро, написанное каким-то гением, который оказался недооценён и ушёл. Начальство не стало это переписывать, потому что уже куча модулей на него завязано, поэтому все остальные дружно водят хоровод вокруг неприкосновенного ядра и продолжают жрать кактус "Java 6". Вы предлашаете ВСЕМ водить хороводы только потому, что у кого-то код невозможно переписать?

ИТ — быстро развивающаяся отрасль, поэтому если как в китайской поговорке, "долго смотреть на воду, можно увидеть как проплывает твой ПРОТУХШИЙ код". Его можно и нужно переписывать, потому что постоянно открываются интересные возможности. Ещё вчера кроме ООП ничего не было. Что представлял "интыпрайз" код? Датасеты, записи, робкие попытки "маппинга". Затем появляется ORM — вау! Пусть это не улучшение языка, но КОД-ТО ПЕРЕПИСЫВАТЬ НАДО! Потому что он серьёзно упрощает всю датабэйзную байду — чо б под эту пляску не заюзать новые фичи языка? (кто б их ещё написал) Затем появляются мощные CPU с 8 ядрами, которые неплохо бы задействовать, народ откапывает богом забытое ФП и понеслась — лямбды, рекурсия, параллельные вычисления и т.п. Попутно неплохо себя показывает метапрограммирование (T4, Nemerle, reflection, dynamic languages и мощный прародитель LISP) — тоже неплохо оптимизирует код! Чо, опять будем сидеть на заплесневелом интыпрайзе? А теперь вообще всех накрыло мобильным пузырём — облака, тонкие клиенты и т.п. Ну и что, нужны тебе эти датасеты? Да ради бога, но это никак не помешает тысячам компаний купить новый, НЕСОВМЕСТИМЫЙ язык и сделать тебя как стоячего — просто уже в силу новых парадигм, а не только фич языка.
Ну как, убедил?
Re[25]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 15.08.14 17:46
Оценка: 12 (1)
Здравствуйте, Qodomoc, Вы писали:

Q>А что-нибудь такое можно будет:

Q>
Q>case List<T> where T : ISmth:
Q>


Не совсем понятно по такому короткому примеру, что имеется в виду. Но я предполагаю, что раз указан констрейнт, то подразумевается, что тип-параметр T является локальным для данного кейса, но не объявлен где-то снаружи, и не участвует в типе выражения, которое мы матчим. Такой сценарий являлся бы вариантом поддержки existential типов, а это не планируется.
Re[9]: [Ann] VS14 Сtp0
От: hi_octane Беларусь  
Дата: 06.06.14 12:33
Оценка: 10 (1)
_>>Ага. Других тасков кроме тех которые в System.Threading.Tasks у нас нет, так что async/await расписываются только в то во что расписываются

S>Пхе, ну сколько можно гнать откровенную пургу? Найди вот тут
Автор: Sinix
Дата: 25.04.14
Task в кастомном awaiter плиз, а потом рассказывай про "нет и нельзя".


Два года назад ты мне за это же самое плюсы ставил
Автор: hi_octane
Дата: 12.10.12
, а тут внезапно с нубом попутал

То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями. Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался? Вот я как рефлектор первый раз на async ещё CTP открыл, так сразу и понял — косяк. Масштаб косяка понял сильно позже, когда первые scheduler'ы писать пришлось. Но там же люди поумнее сидят, а такой хардкод в релиз почему-то пустили.

S>Давай ещё возмущаться, что linq без enumerable не работает

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

S>(заинтересованно) А мсье может предложить другую реализацию Monitor с той же семантикой, но более эффективную? Если семантика различается — то это нифига не lock. Если не различается — надо не допиливать язык, а поменять кривой (по вашему мнению) Monitor.

А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции. А вообще интерфейс ILockable и возможность лочить через него, либо вызывать Monitor если он не поддерживается. Заодно искаропки решилась бы проблема с тем что asnyc/await с локами смешивать нельзя.

S>Влад поправит если что, но как я понял n2 вылез из рамок языка и это скорее убер-фреймворк на стероидах для создания dsl в промышленных масштабах. Ну дык Влад пошёл абсолютно правильным путём — обобщил понятие dsl и макросов, пришёл к пониманию что сам Nemerle вполне dsl и тоже выражается через набор макросов и средства описания типов которыми макросы оперируют. Плюс выкатил абсолютно новую идею что компиляция вообще может быть описана как макро-преобразования с одного dsl в другой, аж до бинарного кода. Вот тебе и n2 — фреймворк и язык в одном флаконе.


S>Будет очень много ломающих изменений, да и работе конца-края пока не видно.

За такую идею я бы сам пару репозиториев поломал, просто из солидарности Тут главное что прогресс виден.
Re[20]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:06
Оценка: 7 (1)
Здравствуйте, VladD2, Вы писали:

VD>Сейчас кода у вас есть Рослин было бы разумно начать работу над алгеброическими типами и паттерн-матчингом.


Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.
Re[3]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 18:10
Оценка: 1 (1)
Здравствуйте, Sinix, Вы писали:

S>Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:


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

S>* Как объявлять такие строки — с префиксом $"Hi, {Name}!" или через "Hi, \{Name\}!"?


Лучше как вразоре. @ (или другой символ) за которым идет выражение C#. В сложных случаях можно будет взять выражение в скобки:
var str = $"Привет, $GetName()!";
str -> Привет, Вася!


S>* Как экранировать скобки в первом случае: как в шарпе, или как в string.Format ("\{" vs "{{")?


Удвоением, чтобы во всех строках работало.

S>* Что насчёт verbatium strings, не будет ли перебором $@"Hi, {Name}!"


Нет. Не будет.

S>* Допустимы ли выражения внутри "{Name}", или только идентификаторы? Вызов методов?


Допустимы.

S>* Поддерживать ли этот формат в [DebuggerDisplay]? API для подобных атрибутов?


Никакой связи. Это всего лишь студийная апишка.

S>* Какая культура должна быть по умолчанию? Нужен ли способ явно указать культуру?


Есть культура ассоциированная с потоком. Ничего больше не нужно.

S>* Добавлять ли синтаксис форматирования от string.Format() ( $"{time:0.0##} second(s) left!")? Кидать ли ошибки при неверном синтаксисе?


Имеет смысл, хотя и без этого можно жить. Можно как раз использовать синтаксис ${...:формат} для таких целей.

S>* Нужна ли возможность заменить interpolator (штуку, которая будет раскрывать выражения в {})? Если да — какие сценарии надо учитывать — razor, sql-форматтеры, биндинг, ещё что-нибудь?


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

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

S>* Нужна ли функция обратного парсинга строки?


Что за чушь?

S>* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic?


Фича статическая. dynamic просто не о чем. В expression tree уже преобразованный код будет.

S>* Как насчёт динамических строк, например, строк из ресурсных сборок?


Очевидно — никак. Это все же языковый литерал, а не динамическая строка. Для динамики остается string.Format и т.п.

S>ну и тд и тп.


Из пальца можно много разных вопросов высосать. А люди будут еще 10 лет палец сосать.

S>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай


Это все отмазки. Со времен рождения языка прошло 12 лет. Куча других языков аналогичную фичу заимело.

Правильным подходом было бы предложить макросы как в Nemerle и Scala (скоро появятся, пока в альфа-версии). Тогда люди смогли бы для себя сами нужные реализации сделать. Причем на альтернативной основе.

Но МС в свой дизайн подобную гибкость не закладывает. Даже в Рослине все гвоздями будет прибито (похоже).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 19:32
Оценка: 1 (1)
Здравствуйте, Sinix, Вы писали:

S>...В общем, roslyn стал фактически неизбежен


Это как раз с сильным пафосом и под воздействием наркотиков прессрелизов.

А по факту где-то перде 2002 годом была сделана одна глобальная (архитектурная) ошибка. Было принято решение писать компилятор C#/VB и language service-ы для них на С++.

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

S>Делать в это время параллельно с рослином очередной big thing — самоубийство в чистом виде.


Строковая интерполяция — это не "big thing". Это вполне себе мелкая фишка. За пару месяцев одним человеком поднимается без проблем. Было бы кому спроектировать.

S>Вот и получается, что в один релиз с рослином укладывается только мелочёвка с синтаксическим сахаром


Связи с этрепрайзом не понял, но строковая интеполяция — это и есть мелкий синтаксический скхар. Уж поверь тому, кто это сам писал.

S>Ну а больше никаких принципиальных преимуществ у string interpolation нет.


Дык у МС никакой подержки нет. Честная строковая интерполяция куда лучше чем просто IDE-шная поддержка. Так что смысл в этом есть. Я все время плююсь когда на Шарпе приходится со строками работать.

В прочем, работать на Шарпе после Немерла или F# по любому не просто. Не проходит ощущение что ходишь с костылями.

S>Если они отпадают, то отпадают и ~70% сценариев использования. Подобное форматирование строк нужно разве что для лога, да и то не всегда. Для вывода пользователю нужна текущая культура + обычно форматирование берёт на себя биндинг в UI-фреймворке. Если запретить вызов методов, то придётся объявлять доп переменные вместо "Score: {GetScore()}" — ещё один минус, если сравнивать с string.Format().


Это ты из из своего опыта вывел? На моей практике $-строки используются довольно часто. Почти все ToString с его помощью реализуются. А одних их 100500 в проекте.

B>>Т.е. мы вводим фичу только для самых употребимых случаев: есть строка, в неё нужно вставить значение.

S>А дальше все её используют и развивать фичу нельзя, т.к. запорется совместимость.

Если объявить фичу экспериментальной, никаких проблем не будет.

B>>Наконец, был озвучен не самый плохой вариант с "ёлочками": « и » (и тогда отпадает конфуз с verbatim: @«»)

S>Не вопрос, осталось оснастить каждую клавиатуру этими ёлочками и заодно убедить кое-какие системы CI что исходники c# в ASCII — это таки XIX векъ и нѣплохо бъ обновiться.

Это не аргумент. В студии кнопки биндятся на раз. Плюс копипаст никто не отменял. Да и быстро появится поддержка IDE. Вопрос только в том, что интерполяция в разных типах строк нужна. А для выделения сплайсов "ёлочки" просто излишни. Подхода Разора тут уместнее.

B>>Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать.

B>>На данный момент никаких проблем не будет, если тупо ввести $ в существующие строки — хочешь — включай фичу, не хочешь (для легаси кода) — не включай.
S>Всемогущество немерла из разряда неуловимого джо.

Ты хоть пробовал на нем писать? Или как про строковую интерполяцию вещаешь заочно с умным видом?

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


Может напомнишь сколько раз строковая интерполяция в Немерле изменялась? И вообще, сколько в Немерле было ломающих изменений?

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


Ага. Главной лицо серьезное делать, когда говоришь о том с чем не знаком. И умных слов типа "это же мэйнстрим". Тогда все поверят, что ты прав. Аргументы — это последнее дело.

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

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

S>Угу, т.е. для вывода в html, для подстановки параметров в sql-запросы и для биндинга фича не годится, ещё минус 10-20% от сценариев использования.


Всемогуторы вообще не нужны. Для работы с XML/HTML нужно отдельное решение которое работает с тегами и знает формат. В том же немерле это отдельный набор макросов. Очень простенький и основанный на парсере ХМЛ-я. Что касается sql-запросов, то для этого есть LINQ. Он уже интегрирован в язык и является отдельным DSL-ем. Не фига его пытаться подменить строковой интерполяцией.

S>>>* Нужна ли функция обратного парсинга строки?

B>>Не понимаю терминологии. О чём речь?
S>
S>TimeSpan now;
S>parse("Time {now:hh:mm:ss}", "Time 22:22:22");
S>WriteLine(now)
S>


Это какая-то нематериализуемая фантазия. Парсинг несколько более сложная дисциплина. Все что можно сделать — это аналог scanf-а. Но он давно показал свою ненужность.

S>Угу, т.е. форматирование строк ресурсов и динамический sql в orm-провайдерах тоже идут лесом, т.к. не нужны(tm).


Именно. На то есть линк. Если захочется можешь сформатировать строку той же интерполяцией. Никто тебе не мешает.

S>Получается, делать interpolated string особого смысла нет.


Ну, да. Все просят потому что глупые.

S>Можно хоть один пригодный для продакшна пример?


Вот из текущего проекта:
https://github.com/JetBrains/Nitra/search?p=1&amp;q=%24%3C%23&amp;type=Code&amp;utf8=%E2%9C%93
Это только для наших рекурсивных строк. Привел именно их, так как гитхаб не умеет искать на $".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 20:19
Оценка: 1 (1)
Здравствуйте, QrystaL, Вы писали:

QL>Пользуюсь с первых дней, после апдейта 8.1.1 стало практически неотличимо от 7.


Пользуясь дома так как в 8.1 все дрова для моей новой машины, но итерфейс поганый. У 7-ки был лучше. Метро-приложения вообще глупая идея на десктопе. Нормальнй скайп днем с огнем пришлось выискивать. Еле нашел. То что пропал способ открыть папку приложения в стартовом меню и посмотреть какие файлы в него входят — это вообще ужасно неудобно. Форменная деградация.

С другой стороны железо знает новое лучше. Работает шустро. В общем, системная часть в порядке. Индерфейс полное дерьмо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 20:52
Оценка: 1 (1)
Здравствуйте, nikov, Вы писали:

N>А когда эти инициализаторы должны выполняться — до тела конструктора или после? до инициализаторов в базовом классе или после? до конструктора базового класса или после?


Просто скопировать инициализатор в бэк-поле (чтобы работало по его логике).

N>Нужно ли выполнять инициализатор свойства в базовом классе, если оно virtual и имеет override в производном классе с другим инициализатором?


Нужно, так есть base.-доступ. Смысла в виртуальных (не абстрактных) авто-свойствах не много. Но переопределяться они ведь и в нескольких потомках могут.

Опять же копируем инициализатор в свое поле (оно же дублируется при оверрайде, если в базовом типе тоже автосвойство было).

N>Компилятор должен быть спроектирован так, чтобы автоматически правильно ответить на все эти вопросы после правки EBNF, правда?


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

Проектирование конечно нужно и важно. Но не по 5 же лет на мелкую фичу тратить. Если у вас с этим проблемы — отдавайте на аутсорс. Я с радостью возьму себе такую подработку.

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

N>И заодно сам сочинить сообщения об ошибках для всех некорректных случаев? Или достаточно сказать "ваша программа не соответствует EBNF"?


Почините в процессе тестирования. Это не бином Ньютона. Тут скорее вопрос в том чему нужно отдавать приоритеты. В МС они частенько отдаются пиару/промывки мозга. Причем сначала всем промывают мозг на тему того почему фича/подход не нужна, а потом почему она необходима.

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

А мокросы нужны языку хотя бы для тестирования новых фич и внутренней разработки.

В прочем, это даже хорошо, что в МС не делают все как надо с первого раза. Это дает жить и другим игрокам на рынке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 05.06.14 12:52
Оценка: :)
Здравствуйте, btn1, Вы писали:


B>Я не корю их за то, что такую тривиальщину не сделали до этого (хотя и могли). Я не понимаю, почему сейчас это отнимает столько времени!? Ты ж прогер, просто сядь за листок и набросай псевдокод — да там от силы 20 строк получится!

Всё просто — MS не получает денег за добавление новых фич. Они получают деньги за переход старых клиентов на новую версию и приманивание новых клиентов старыми. Выше
Автор: Sinix
Дата: 05.06.14
я написал примерный расклад по количеству пользователей и по тому, как ломающие изменения сказываются на доходах.

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

В c# team это правило действовало буквально с начала разработки языка. И буквально с первых дней разработчиков "вежливо" спрашивали "где моя любимая фича?!! c# — отстой!!! вы дибилы!!!". Тема обсуждалась сотни раз, вот и вот самые популярные объяснения. Тем не менее, люди отказываются верить, что таких вопросов на каждой итерации всплывает сотни, что сделать каждый из них нужно только за счёт других фич, и что большую часть каждого релиза занимают "мажорные" фичи, на которые сделана стратегическая ставка и затрагивать их нельзя вот никак. Совсем.

Даже про "20 строк кода" отвечалось неоднократно. Рекомендую вот эту классику.

B>Ну так в чём твоя ирония по поводу "великого btn1" и лопухов, которые даже занимаясь вплотную компилятором, не просекли вовремя абсолютную идентичность начальных фаз компиляции для собственно компилятора и подсветки??

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

Маленький пример — экспансивное развитие шарпа привело к тому, что, например компиляция каждого метода выполнялась в ~26 проходов (это до async/await и без учёта некоторых оптимизаций). Т.е. добавлене каждой новой фичи (пусть и "в 20 строк") ещё ненамного замедляло общее время компиляции и добавляло минусов в копилку следующих фич — для них порог добавления становился ещё выше. С выходом рослина это конечно не так актуально, тем не менее надо понимать, что стоимость добавления любой мелочи зависит не столько от её размера в коде, сколько от её влияния на экосистему шарпа в целом.

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


B>Я не хочу хвалиться, но связь тут очевидна и то, что это не было сделано даже таким гигантом как M$, говорит лишь о том, что и там не боги компиляторы обжигают — такие же спецы как мы с тобой (если не хуже). А пипец всей ситуации во вранье, которое эти ламеры впаривают нам как "обоснование отказа", хотя фактически оправдывают свою лень и тупость.

Смотри как парадоксально. Есть компании, которые закрыты донельзя, никогда не рассказывают о внутренностях продуктов, обучение проводят за неиллюзорные бабки, но при этом массовый мейнстримный рынок так и не заняли. Oracle, axapta (пока она ещё была, конечно), SAP, crytek (до недавнего времени) — в каждой области есть такие примеры. А есть компании, сотрудники которых забесплатно выкладывают в веб проблемы разработки под рынок в полмиллиона весьма привередливых клиентов и, главное, учат с подобными проблемами бороться.

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

Наверно, во всём этом есть какая-то логика и мораль, но я её пока не нашёл.
Re[6]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 05.06.14 13:38
Оценка: -1
Здравствуйте, hi_octane, Вы писали:

_>Дык именно из-за того что изначально рассматриваются мини-фичи поштучно именно так как ты описал, и реализуются каждая отдельно, у команды C# есть наверное уже 6-й несовместимый способ описания/генерации C#-кода: expression trees, та модель которая под dynamic, почти уже умерший CodeDom, их внутреннее представление в старых компиляторах C#, их VsCodeModel представление для автокомплита/рефакторинга в студии до Roslyn, и, наконец, Roslyn. Думаю я ещё пару упустил просто потому что не инсайдер

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

Если серьёзно — в любом крупном проекте оно всегда так. Или делается то, что реально здесь и сейчас, или радостно фейлимся под комментарий "зато мы лучшие". Альтернатив я что-то не видел.

_>Кстати в том же Roslyn, когда я на него смотрел, получается что он заточен буквально на два языка,

[кэп]Потому что он и писался как замена unmanaged-компиляторам c#/vb[/кэп]. Ну и дадим слово самим авторам:

Hi Paul,

It's definitely a ton of work to add another language. As you know, tackling C# and VB has taken several years, so you could expect a similar level of investment for additional languages. Support for another language might appear at some point in the future, but not in the short term.

Dustin Campbell | Senior Program Manager | Roslyn Visual Basic and C# Language Services

(c)
и

Is F# part of the Roslyn project?
No, F# isn't part of the Roslyn project and will not expose the same compiler APIs as it will for Visual Basic and C#. Roslyn is focused specifically on Visual Basic and C#.

There are several reasons why F# isn't in scope for the Roslyn project. One reason is that the F# compiler is already written in F#, but more so because Microsoft needed to limit the scope of the Roslyn project to a reasonable size. Remember that the languages team is also busy completing Visual Basic 11 and C# 5. There are also multiple aspects of F# that don't map well to the Roslyn APIs, such as the shared symbol model.

(c)

Кстати, про "ton of work to add another language" — это они буквально, сравни соотношение частей core и c# в рослине.

Других популярных managed-языков у MS для нас нет, так что что ещё, начиная с первого релиза нужно было подсадить на roslyn, мне решительно непонятно


_>И вот это:

S>>* объяснить 600k клиентам, что если им что-то не нравится, они всегда могут сами допилить язык до нужного им состояния.
_>не понадобилось бы. Сама возможность "сделать чего-то", при достаточно большом комьюнити, автоматически приводит к тому что это чего-то появляется, даже если не планировалось. И потом растут как грибы туториалы на кодепрожектах, хабрах и в блогах.

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

Чисто для примера — http://phone.codeplex.com/ Спрос как бы есть (коммерческие варианты начинаются с $100 per developer per year), тем не менее проект активно развивается и допиливается аж не могу как. "Latest release date – August 15th 2013", ага.

Disclaimer: я ничего не имею против хорошего годного коммерческого опенсорса с контролирующей организацией/лидером в центре, но выше-то речь не о нём


S>>С вашим вариантом фичу надо ждать ближе к седьмому шарпу

_>Я верю что к тому времени уже Nitra выйдет
Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом
Автор(ы): Чистяков Владислав Юрьевич
Дата: 15.05.2012
В данной статье рассказывается о новом проекте языкового фрэймворка – N2
— развивать можно, но слишком скучно:

При работе над Nemerle нами (группой RSDN) было выявлено несколько архитектурных и множество проектных недостатков Nemerle. Не будут вдаваться в подробности, но именно желание их устранить привело нас к проекту N2. N2 изначально задумывался как принципиально новая версия языка Nemerle, но в итоге он превратился в нечто большее, чем отдельный язык программирования. Он превратился в языковый фреймворк или Toolkit.

Re[7]: [Ann] VS14 Сtp0
От: hi_octane Беларусь  
Дата: 05.06.14 15:45
Оценка: +1
S>Если серьёзно — в любом крупном проекте оно всегда так. Или делается то, что реально здесь и сейчас, или радостно фейлимся под комментарий "зато мы лучшие". Альтернатив я что-то не видел.

В крупных проектах несколько разных штуковин для одного и того же появляются, чаще всего, как следствие сохранения обратной совместимости при выкатывании новых версий. А тут — им реально в VS 2002 были нужны VB.NET, C# и они сходу запилили собственно компиляторы, студийный парсер для Intellisense, CodeDom и (судя по отличиям в поведении) ещё и отдельный какой-то парсер для отладчика. Мне что-то не верится что, например лично ты, пошёл бы таким-же путём в первой же версии продукта

S>Других популярных managed-языков у MS для нас нет, так что что ещё, начиная с первого релиза нужно было подсадить на roslyn, мне решительно непонятно


Ага. Других тасков кроме тех которые в System.Threading.Tasks у нас нет, так что async/await расписываются только в то во что расписываются, других Monitor кроме того одного в CLR не задумывалось, поэтому lock у нас бывает только такой, и т.д, и т.п.

S>Чисто для примера — http://phone.codeplex.com/ Спрос как бы есть (коммерческие варианты начинаются с $100 per developer per year), тем не менее проект активно развивается и допиливается аж не могу как. "Latest release date – August 15th 2013", ага.


Такие штуковины надо не просто выкатывать и ждать что комьюнити подхватит, а оставлять народ на развитие. Тот же ASP.NET заброшенностью не страдает, хотя уже весь в опен-сорс.

S>Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом
Автор(ы): Чистяков Владислав Юрьевич
Дата: 15.05.2012
В данной статье рассказывается о новом проекте языкового фрэймворка – N2
— развивать можно, но слишком скучно:


В смысле? Nitra это же и есть второй немерл, где ты там увидел неудобняк?
Re[8]: Давайте будем лапидарными
От: Qbit86 Кипр
Дата: 05.06.14 19:26
Оценка: :)
Здравствуйте, btn1, Вы писали:

Заскипан оверквотинг, не надо так больше! H_D
Ох, btn1, твои комментарии просто рвут мне сердце и почтовый ящик.
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 06.06.14 13:52
Оценка: +1
Здравствуйте, hi_octane, Вы писали:

S>>Пхе, ну сколько можно гнать откровенную пургу? Найди вот тут
Автор: Sinix
Дата: 25.04.14
Task в кастомном awaiter плиз, а потом рассказывай про "нет и нельзя".

_>Два года назад ты мне за это же самое плюсы ставил
Автор: hi_octane
Дата: 12.10.12
, а тут внезапно с нубом попутал


Ну, могу или там плюсик убрать или тут извиниться. Выбирай
Если серьёзно, на практике всё не так, как в теории. Внезапно оказывается, что "хардкод await на Task" ничему не мешает. Точно так же, как хардкод yield return на IEnumerable<>.

_>То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями.


При желании хардкод заменяется на IAsyncStateMachine и IAsyncMethodBuilder, т.е. в будущем никто не запретит добавить в INotifyCompletion
IAsyncMethodBuilder<IAwaitable<T>> GetMethodBuilder();

и извращаться как заблагорассудится. На практике смысла в этом не больше, чем в замене итератора для yield return. Посмотри внутренности дефолтного AsyncMethodBuilder, там весь функционал по большому счёту сводится к m_Task.SetResult. Не, при большом желании можно переписать таск с 0 (где-то пара человекомесяцев минимум), но зачем — мне решительно непонятно. Разве что чтобы возмущаться "опять используют велосипед вместо готового решения"

_>Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался?

Потому же, почему нельзя вернуть IMyEnumerable<T> из кастомного итератора — во, первых, фичу никто не спроектировал, не закодил, не протестировал и не отправил в продакшн. Во-вторых, идея на корню рубится типовыми сценариями использования. Для IEnumerable это linq, для async — await. Как через них будешь свой чудо-тип протаскивать?

Только не надо начинать "вот у MS разработчики есть, пусть они и думают". Они как раз думают перед тем, как делать, поэтому шарп практически не страдает от избытка преждевременных фич.

S>>Давай ещё возмущаться, что linq без enumerable не работает

_>Про линк я ничего не говорил. Как раз наоборот удивляюсь как они догадались его почти нормальным сделать.
Тем не менее, принципы 1-в-1, даже код для разворачивания await и yield частично общий.


_>А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции.

Ну ок, можно попросить чтоб в следующей версии добавился
ILockable { bool TryEnter(); Exit(); }

только нужно ещё обосновать, зачем это щастье надо. Потому что внезапно выяснится, что на практике в rwlock надо передавать таймаут и/или CancellationToken и что на самом деле пользователей интересует совсем другое. Например, удобный синтаксис для await lock, устойчивые к thread.Abort() using-и и нормальный синтаксис для actor model, чтобы наконец перестать возиться с наногруппировками и писать легкомасштабируемый код.

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

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

S>>Будет очень много ломающих изменений, да и работе конца-края пока не видно.

_>За такую идею я бы сам пару репозиториев поломал, просто из солидарности Тут главное что прогресс виден.

Угу. Главное, чтобы потом парней не захватила ещё более великая идея. Ещё раз им удачи!
Re[2]: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 17.06.14 13:53
Оценка: +1
Интересно, что в CTP пока приходится писать так:
Customer?.Order?.ShipDate?.Year

Несмотря на это обсуждение.
Возможно, не допилили к выпуску.
Re[3]: [Ann] VS14 Сtp0
От: btn1  
Дата: 23.06.14 01:12
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

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


B>>проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")


AVK>Надо внимательнее читать сопроводительный текст. Выставлять не 6.0, а Experimental.


1. Читал, выставлял — бестолку. В какой-то момент ворнинги пропали, но перезапущенная студия снова разругалась.
2. Какого чёрта в свойствах проекта есть C# 6.0, но при этом нету Experimental? Какая между ними разница? И наконец, если уж выкатили CTP (априори "нерабочая" среда), можно уж было поднапрячь зад и сразу создавать проекты с необходимым значением языка — CTP для того и предназначен, чтобы тестировать НОВЫЕ ФИЧИ, которые по дебильному стечению обстоятельств недоступны искаропки.

Что делал я: создал проект, написал неработающие фичи, среда разругалась. Проект сохранил, выставил язык Experimental, открыл проект — вроде бы предупреждения исчезли, потом что-то отредактировал, компильнул — среда опять ушла в отказ и C# 6.0 перестала понимать. Затем выставил 6.0 через свойства проекта — тоже бестолку.
И опять возвращаемся к вопросу о жадности: сколько можно экономить на индусах и выкатывать откровенный отстой?
Re[3]: [Ann] VS14 Сtp0
От: btn1  
Дата: 23.06.14 01:26
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Надо внимательнее читать сопроводительный текст. Выставлять не 6.0, а Experimental.


Прямо сейчас, ещё раз на свежую голову всё выставил — бестолку. Вот скрин:



Я понимаю, что это CTP, но почему-то на выходе у мелкософта получается WTF.
Re[4]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 01:54
Оценка: +1
Здравствуйте, btn1, Вы писали:

B>Прямо сейчас, ещё раз на свежую голову всё выставил — бестолку. Вот скрин:


Почитай внимательно здесь: http://blogs.msdn.com/b/csharpfaq/archive/2014/06/03/visual-studio-14-ctp-now-available.aspx



Попробуй написать
    <LangVersion>experimental</LangVersion>

как указано в инструкции. Фичи не включены по умолчанию, потому что они экспериментальные, и могут быть убраны или существенно измениться к релизу C# 6.0.
Re[10]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 16:10
Оценка: +1
Здравствуйте, kleng, Вы писали:

K>
K>        enum Foo { Bar1 = 0, Bar2 }

K>        static void Main(string[] args)
K>        {
K>            var foo = (Foo)100; // WTF???
K>        }
K>


K>Глядя на такие фокусы, мне с трудом верится в высокий профессиональный уровень разработчиков компилятора.


Ты читал спецификацию C#, спецификацию CLI? Они требуют, чтобы енумы работали именно так.
Есть метод, который позволяет явно проверить, что значение енума соответствует одному из именованных элементов.
Re[12]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 18:26
Оценка: +1
Здравствуйте, kleng, Вы писали:

N>>Ты читал спецификацию C#, спецификацию CLI? Они требуют, чтобы енумы работали именно так.


K>Ну если нелепость внесли в спецификацию, то это конечно уже не нелепость.


Спецификация не является описанием того, как разработчики компилятора сделали ту или иную фичу. Создание спецификации — это первичный и отдельный процесс, вовлекающий множество заинтересованных сторон, и проходящий через международные организации по стандартизации (ECMA, ISO). Есть способы повлиять на этот процесс, если ты считаешь, что дизайн является неудачным и требует изменений. Но от квалифицированного разработчика компилятора уж никак не ожидается, что он будет оценивать лепость или нелепость требований, закреплённых в спецификации, и отклоняться от них по своему усмотрению.
Re[7]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 18:32
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

B>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).

G>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?

Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".

G>С VM проще, ничего не мешает иметь несколько VM внутри процесса side-by-side и даже делать прозрачный маршалинг между ними. При этом CLR4 совместим с CLR2, то есть может в свою ВМ грузить сборки под старый фреймворк, так что и на этом уровне совместимость очень тщательно поддерживается. Хотя это и не так важно.


Вообще-то косяков выше крыши. Фрейморки 4.0, 4.5 и 4.5.1 не совсем совместимы. Есть куча веселых проблем. Например, программа скомпилированная через Reflection.Emit на 4.5.1 фреймворке может не запуститься под 4.0, так как типы будут прибиндены так как они лежат в 4.5.1 сборках.

Было большой ошибкой делать 4.5.* фреймворки обновлениями для 4.0. Так что с совместимостью у донете все не очень хорошо.

Про приседания с версиями сборок я вообще молчу.

Но, конечно же, это не оправдывает создание не совместимости на уровне языка.

G>Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6 (2006 год), а некоторые до сих пор используют Java 1.4. При этом с совместимостью у Java не сильно хуже, чем у C#.


Я знаю не мало людей которые не могли перейти с одной версии фреймворка на другую. Это не аргумент. В Яве все примерно тоже самое. Кто по шустрее переходит. Кто по осторожнее тормозит с переходом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: [Ann] VS14 Сtp0
От: kleng  
Дата: 23.06.14 19:51
Оценка: +1
Здравствуйте, nikov, Вы писали:

N>Спеку можно поменять. Но порог изменений для уже выпущенного продукта очень высокий из-за требований обратной совместимости


Doublespeak 80 уровня.
В нормальных условиях, сначала создается и обкатывается прототип, и уже потом по нему пишется спека и подается на стандартизацию.
Re[17]: [Ann] VS14 Сtp0
От: kleng  
Дата: 23.06.14 21:20
Оценка: -1
Здравствуйте, nikov, Вы писали:

N>Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?


Только не надо юлить. Реализация кривая, и глупо с этим спорить.
Re[8]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 21:30
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


N>>Прототипы писали, и там далеко не 20 строк.


VD>Не 20. Но и не года несустветная. За месяц за пилить можно без проблем.


Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке? Между прочим, Roslyn — это open source библиотека. Ты можешь реализовывать фичи и посылать пул реквесты.

VD>Какие-то отмазки. Ну, да содержут, доллжны и т.п. Что в этом страшнокго то? Берем строку, парсим. Получаем отрезки строк и отрежки кода. Трансформируем выражение (генерируем код) и получаем окончательный вариант который и подвергаем типизации. все описанное выше получается в автомате.


В Nemerle работает Extract Method рефакторинг с интерполированными строками? А с частью выражения после $ в интерполированной строке?

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

VD>Нулы, конечно же, нужно превращать в пустые строки. Исключения при работе со строками никому не нужны.
VD>Если кому-то понадобится специальная обработка, он преобразование в функцию завернет.
VD>Это не суть важно. Если кому-то не понравится ваше поведение он всегда его сможет подменить переводя объект в строку самостоятельно. Надо выбрать одну стратегию и придерживаться ее везде и всегда. Или тупо использовать паттерн .ToString() (перекрыт не перекрыт — не важно) или всегда кастить к обжекту и звать виртуальный.

Видишь, все эти пункты требуют принятия каких-то решений. И это не может быть сделано одним человеком, так как человеку свойственно ошибаться. И мы не можем потом поломать код у тысяч разработчиков, потому что какое-то решение было неудачным и нуждается в исправлении. А неудачные (или даже в чём-то спорные решения) приведут к тому, что люди потом будут ругать Microsoft десятилетиями (см. этот тред выше).
Re[8]: [Ann] VS14 Сtp0
От: DarthSidius  
Дата: 24.06.14 12:58
Оценка: :)
Здравствуйте, btn1, Вы писали:

Читаю тебя с огромным удовольствием
Давно не получал таких энорфинов
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>
♠♠♥♠♠♦♥
Re[20]: [Ann] VS14 Сtp0
От: fddima  
Дата: 24.06.14 22:59
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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

Нет, не спорная. Она именно такая, которая нужна. Это теоретикам, видимо, навроде тебя она кажется спорной.
Поведение enum — как минимум наследуется от прародителей.
Кроме того, enum handling в WCF — отвратительно отвратительный (!!!). А именно до безобразия строгий. Оно видители не может принять то, что не задекларировано. Мы пытались на основе WCF реализовать действующий протокол — и это местами enum — не то что было проблемой, просто выглядело глупым. Сейчас спецификация объявляет флаговое поле с такими значениями, потом их добавляет. Но это никак не значит, что клиент (т.е. мы), обязаны их обрабатывать — всё что мы обязаны — это их хранить. И неизвестные флаги — не повод отвергать входящее сообщение. Это всё в противовес этой "нелогичности".
Нелогично — это использовать enum-ы так, как они не использовались до этого.
Поэтому все эти теоретизации — это глупость. enum — был и есть одним из надвидов из основных примитивных типов — почему бы ему таким и не быть.
Если очень такого хочется — то наверное нужно сделать другой тип. Почему бы нет? Хотя решения приведенной проблемы — тысяча. Только они никак не помогут тому, что код всё равно должен быть "bullet-proof". А именно — если он анализирует enum — то должен покрывать все случаи. Если это флаги — то и компилятор то по факту никак не поможет (флаги и их возможные и допустимые варианты — для компилятора — загадка).
Re[10]: [Ann] VS14 Сtp0
От: _NN_ www.nemerleweb.com
Дата: 25.06.14 09:10
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


_NN>>Так ведь сделали ключиком


VD>Я говорил о том, что можно было бы сделать ключ конкретно для этой фичи.


Имеется ввиду официальная опция в проекте и официальный ключ компилятора ?
В таком случае конечно только за.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[12]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.06.14 08:21
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Нормальнй скайп днем с огнем пришлось выискивать. Еле нашел.


Где ты искал то? Потому что на skype.com жмем кнопку Get Skype и попадаем сразу на страницук Skype for Windows desktop.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 19.08.14 09:08
Оценка: +1
Вышел CTP3.
Подробности здесь и здесь.

.NET Native is integrated into Visual Studio 14 for the first time with CTP 3.

Re: [Ann] VS14 Сtp0
От: btn1  
Дата: 04.06.14 12:03
Оценка:
Здравствуйте, Sinix, Вы писали:

S>... c# 6 со всеми плюшками


Да ё-моё! "String interpolation" всё ещё MAY BE?!?!! Да эти клоуны и к 22 веку не напишут человеческий вывод строк!
Re: [Ann] VS14 Сtp0
От: btn1  
Дата: 04.06.14 20:28
Оценка:
Здравствуйте, Sinix, Вы писали:

S>visual-studio-14-ctp


Может я чё не понимаю... она что, ТОЛЬКО НА ВОСЬМЁРКЕ РАБОТАЕТ??? Только что попробовал поставить на Win7 SP1 — "нужна новая версия винды"! Куда новее-то? Или они восьмёрсу тоже "виндой" считают??
Re[3]: [Ann] VS14 Сtp0
От: hi_octane Беларусь  
Дата: 05.06.14 10:04
Оценка:
S>Тем более что добавить новую фишку и ничего не поломать не так-то просто. Вот тебе навскидку вопросы:
S>ну и тд и тп.

4 года назад мы спорили о микроменеджменте фич языка
Автор: hi_octane
Дата: 03.11.10
. Эта штука ущербна по определению. И Эрик Липперт уже ушёл, а ничего в головах людей работающих над компилятором C# не изменилось

Поднимать вопрос за вопросом можно до бесконечности, но если отойти на шаг выше, и добавить добавить Compile-Time String Formatter класс, использующих API Roslyn и контекст где описана строка — он сам построит дерево вызовов ToString для аргументов и подсунет текущую культуру, текущий форматтер и т.п. Плюс открытая реализация чтобы его можно было подменить/расширить, и тогда базовый вариант будет доступен всем, а на кодеплексе сами размножатся самые нетривиальные форматтеры, от поддерживающих абсолютно все фичи которые там обсуждаются + те до которых мы никогда не додумаемся.
Re[2]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 05.06.14 11:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Только со стороны студии поддержки никакой, увы. Все новые конструкции отображаются как ошибки и ломают интеллисенс. И надо ручками задать <LangVersion>Experimental</LangVersion> в файле проекта.

Угу, спасибо за поправки! Мопед не мой, у самого руки пока не дошли поставить.
Re[5]: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 11:53
Оценка:
Здравствуйте, Sinix, Вы писали:

S>1. До .net 4 каждая версия шарпа дополнялась очередной big thing — согласованным набором возможностей, которые (это я сейчас без пафоса) кардинально упрощали реализацию той или иной типовой задачи. Генерики, linq + лямбды, dynamic, await etc, общее направление, думаю, понятно. При этом на мелкие фишки или на серьёзные доработки внутренностей компилятора время не выделялось за очень редкими исключениями — было банально не до них.


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

S>* Дальше добавлять возможности в компилятор весьма проблематично, потенциал для развития исчерпан. Дошло до того, что в vs фактически работало два компилятора — стандартный csc.exe + псевдокомпилятор для "живой" подсветки ошибок


Ну так в чём твоя ирония по поводу "великого btn1" и лопухов, которые даже занимаясь вплотную компилятором, не просекли вовремя абсолютную идентичность начальных фаз компиляции для собственно компилятора и подсветки??
Я не хочу хвалиться, но связь тут очевидна и то, что это не было сделано даже таким гигантом как M$, говорит лишь о том, что и там не боги компиляторы обжигают — такие же спецы как мы с тобой (если не хуже). А пипец всей ситуации во вранье, которое эти ламеры впаривают нам как "обоснование отказа", хотя фактически оправдывают свою лень и тупость. Так бы и сказали: "знаете, ребят, не просите вы ваши фичи — у нас там такой говнокод, что мама не горюй — сами едва вставляем фичи! Вы подождите, пока мы проект до ручки Рослина не доведём, а там посмотрим!" — вот это честно и по-мужски. А то начинается — "совместимость, рентабельность, фичастость"...
Знаешь, это как с электростеклоподъёмником — ни бог весть какая важная фича, но с ним жить становится чуточку приятнее — вот точно так же они обязаны понимать запрашиваемые фичи: можно и string.Format написать, но у меня и без этого хватает гемороя по юзанью их же говнокода — почему бы им не облегчить мне жизнь интерполяционными строками? В конце концов, они ж не себе этот долбаный C# ваяют — это ДЛЯ НАС они пишут! Чтобы мы, программисты, писали ПОД ИХ ВИНДУ приложения, повышая им же доходы. Чуешь, кто кому нужнее?

S>В общем, roslyn стал фактически неизбежен


Это было очевидно ровно в тот момент, когда кто-то умный воскликнул: "а давайте в редакторе подсвечивать код!". Это было примерно в 1993, Turbo Pascal и всё такое... (по-моему, даже Turbo C не подсвечивал кода!)

S>Делать в это время параллельно с рослином очередной big thing...


Да помилуй, какая big thing??!! ДВАДЦАТЬ СТРОК КОДА на фичу, которая уже 30 лет в продакшене! Это не я должен думать "где взять ресурсы", а они, когда умно рисовали свои квадраты со стрелками, должны были подумать — сколько мы гемороимся со строками и насколько удобным это должно быть, чтобы не парить мозг. Да и "ресурсы"... от чьего лица вы это говорите? От лица многомиллиардной компании? Это у БГ штоле нехватило денег на квалифицированные кадры? Ну так не надо нанимать индусов, мать твою Билли за ногу! РОССИЯ — вот родина программистов!

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


Ну вот! Ровно этими же словами описываются interpolation strings! Один-в-один. Чо сложного-то? Ты читал их обсуждения? Там уже десять страниц(!!!!!) соплежуйства "а вот как бы нам записать сроку?" — и это на фоне тех двух часов, которые эти ***опые тюлени могли потратить в выходные на фичу, которую ждут тысячи программистов!

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


Э-не! Вы, батенька, не путайте зализывание собственных косяков с развитием языка! То, что Рослин не был написан — это ИХ проблема! И только сейчас, спустя 10 лет, им кликнуло "блин, да у нас половина кода дублируется в студии!".

Да и в целом... вот тебе лично Рослин нужен? Мне — нет, разве что на "поиграть". Он не повышает качество моей архитектуры и не делает страшное упрощение разработки — всего лишь "правильно" подсвечивает код. Ну так и чего радоваться-то? Я фичам радуюсь, а не тому, как M$ выпутывается из ямы, которую сам себе вырыл.

S>... у команды хватало дел и без подобной мелочёвки. Возни много, пользы мало (учитывая конкуренцию с string.Format).


См. выше про стеклоподъёмник. Писать можно и в notepad, но чего ради тогда жить?...

S>Если они отпадают, то отпадают и ~70% сценариев использования.


Да ладно?? Уж не надо мне рассказывать про проценты — Чурову расскажи! У меня все программы кишмя кишат "abc"+def, string.Format и т.п. Мне ОЧЕНЬ сильно помогли бы эти строки уже читабельностью, не говоря про меньший риск ошибок.

S>...Для вывода пользователю нужна текущая культура + ....


Да мне пофиг! Ты опять скатываешься к "универсальным строкам вселенского применения", хотя я предупреждал: это НЕ ЗАМЕНА string.Format! Что тут сложного понять-то? Надо все плюшки форматирования — юзай старую функцию, но дай для ПРОСТЫХ вещей ПРОСТЫЕ решения!

S> Если запретить вызов методов, то придётся объявлять доп переменные вместо "Score: {GetScore()}"


См. выше — ты опять пытаешься впихать в "подстановку" всё, что можешь только придумать — зачем?? Просто ответь: зачем вообще нужны IS? Ты _суть_ этих строк понимаешь? (особенно в свете уже существующего string.Format) string.Format УЖЕ ЕСТЬ. Точка. Проблема всех форматирований, культур-мультур решена! И вот теперь ПОМИМО ВСЕГО ЭТОГО мы просим: сделайте нам ПРОСТУЮ, НАИПРОСТЕЙШУЮ, САМУЮ ТРИВИАЛЬНУЮ, ДУБОВУЮ, ТОПОРНУЮ подстановку переменная->значение! Точка. Всё, никаких фантазий — только переменную! Стринги? Плётки? Дильдо? НЕТ! Только переменную. Этого ДОСТАТОЧНО ДЛЯ СЧАСТЬЯ.
Как ещё можно яйцеголовым донести, что иногда людям действительно нужны только двухдюймовые дыры? Не свёрла, не лазер, не перфоратор, а просто одна двухдюймовая дыра! Эх...


S>А дальше все её используют и развивать фичу нельзя, т.к. запорется совместимость.


А не надо "развивать" — это тот же процесс "накручивания функциональности", от которого я предостерегал выше! Только переменная. Точка.

S>Нельзя. Ибо энтерпрайз и софт десятилетней давности должен собираться без подобных проблем.


См. выше — НЕ НУЖНО "интыпрайзу" лезть в авангард! Юзай C# 5.0 и береги "суперкод". Но новые фичи должны появляться.

S>Не вопрос, осталось оснастить каждую клавиатуру этими ёлочками и заодно убедить кое-какие системы CI что исходники c# в ASCII — это таки XIX векъ и нѣплохо бъ обновiться.


хаха Ну вот видишь! Ты же сам видишь абсурдность ситуации: говноконтора выпускает говнопродукт, а ты, вместо того, чтобы послать их к чертям, будешь СЕБЯ под них подстраивать?? Это НАШ язык — он специально пректировался под юникод, чтобы мы никогда больше не имели проблем а-ля Дельфи, где русские программы работали только на русской винде.

S>Угу, т.е. для вывода в html, для подстановки параметров в sql-запросы и для биндинга фича не годится, ещё минус 10-20% от сценариев использования.


Для вывода в HTML/SQL/Хренуэль существуют свои частные эскейперы. С чего ты решил, что подстановка должна уметь с ними работать? С чего ты вообще привязываешь какие-то чужеродные форматы к языку программирования?
C# — это ЯП _общего_назначения_, т.е. у него ОДИН синтаксис для решения всех задач. C# никогда не был (И НЕ БУДЕТ) языком с "красивой интеграцией DSL" — для этого как раз Немерле и нужен
Кроме того, а чего ты прицепился к IS с этими HTML? А сейчас что — можно вставлять без эскейпинга в HTML? SQL? Нет. Ну так чего ты хочешь-то? Это ВСТАВКА ЗНАЧЕНИЯ ПЕРЕМЕННОЙ в стандартную строку языка C#. Ни больше, ни меньше.

S>>>* Нужна ли функция обратного парсинга строки?

S>parse("Time {now:hh:mm:ss}", "Time 22:22:22");

Ну и чего? Ну распарсил ты строку с датой (что тут "обратного"? Это обычный парсинг строки в нативный тип), как это относится к IS? Пример что ли приведи, но не забывай главную функцию IS.

S>Угу, т.е. форматирование строк ресурсов и динамический sql в orm-провайдерах тоже идут лесом, т.к. не нужны(tm).


Да, и кофе IS тоже не варит! Что тут такого-то? СЕЙЧАС у тебя вообще ничего нет — живут твои expressions tree? Живут. Ну а теперь в программе появится IS — всем счастье! Зачем всё усложнять?

S>Получается, делать interpolated string особого смысла нет.


Есть. Смысл был указан выше.

S>)) Начнём с того, что string.concat должен применяться только если не задано форматирование, $"Money {modey:N2}" через concat не сделаешь.


Это та же старая песня "IS не умеет {перечисление всякой лабуды, до которой автору не было раньше дела}". Вернись к абзацу с "дильдо" — он всё объясняет.
Re[8]: [Ann] VS14 Сtp0
От: QrystaL Украина  
Дата: 05.06.14 17:08
Оценка:
Здравствуйте, btn1, Вы писали:
B>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8? _ВСЕ_, от домохозяйки до программиста, знают — вышло полное гуано с абсолютно непотребным интерфейсом. Какие продажи ждут студию?

Сколько желчи
Тему можно переносить в КСВ
Re[9]: Давайте будем лапидарными
От: btn1  
Дата: 05.06.14 19:45
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Ох, btn1, твои комментарии просто рвут мне сердце и почтовый ящик.


эээ... не маловато комментариев для такого оверквотинга?
Re: [Ann] VS14 Сtp0
От: btn1  
Дата: 05.06.14 19:47
Оценка:
Вопрос залу: кто-нибудь ставил ЭТО? Я водрузил студию на виртуалку, создал проект, проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")
Re[6]: [Ann] VS14 Сtp0
От: fddima  
Дата: 05.06.14 22:40
Оценка:
Здравствуйте, btn1, Вы писали:

B>+1. Ни в одной конторе, где работал, народ даже не думает о каких то Right-to-left, decimal point/comma и т.п. — софт шёл исключительно на англоязычный рынок, везде "десятичная точка", а с датами вообще всё просто — хранят как год-месяц-день-и-т-д, а выводят дефолтовым (читай, системным) способом.

Я сталкивался с другой проблемой. Документ не парсится, потому что культура не учитывалась. При этом, документы имели достаточно чёткое определение, а именно, что никаких там запятых вместо точек быть не должно. Раз софт формирует такое (наш софт) — понятно что кто-то ошибся. Но я так и не встретил ситуаций, даже с UI — где форматы не были бы оговорены заранее. Да, есть какой-то сегмент, который должен полагаться на системные настройки — но даже в этой нише, отсутствие опции выбора той же культуры или бесит, или оно нафиг не нужно. Неплохим всегда в плохом смысле этого слова был excel, ранние версии которого не понимались между локализациями (или я брешу?). По моему — не понимались.
Re[8]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 06.06.14 05:48
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>В крупных проектах несколько разных штуковин для одного и того же появляются, чаще всего, как следствие сохранения обратной совместимости при выкатывании новых версий. А тут — им реально в VS 2002 были нужны VB.NET, C# и они сходу запилили собственно компиляторы, студийный парсер для Intellisense, CodeDom и (судя по отличиям в поведении) ещё и отдельный какой-то парсер для отладчика. Мне что-то не верится что, например лично ты, пошёл бы таким-же путём в первой же версии продукта


Насколько помню, из действительно независимых реализаций был только CodeDom и аналогичная SolutionModel для VS. Парсеры в VS хоть и отличались, но пилились на основе кода компиляторов. Учитывая, что vs team, c# team и vb team в то время не были объединены в одну команду, объём работы и общее непонимание, что из этого выйдет — и так неплохо.

S>>Других популярных managed-языков у MS для нас нет, так что что ещё, начиная с первого релиза нужно было подсадить на roslyn, мне решительно непонятно

_>Ага. Других тасков кроме тех которые в System.Threading.Tasks у нас нет, так что async/await расписываются только в то во что расписываются

Пхе, ну сколько можно гнать откровенную пургу? Найди вот тут
Автор: Sinix
Дата: 25.04.14
Task в кастомном awaiter плиз, а потом рассказывай про "нет и нельзя".
Давай ещё возмущаться, что linq без enumerable не работает (хотя это не так от слова абсолютно, т.е. совсем).

Кстати, Липперт перед уходом из MS намекал, что идею с syntax pattern неплохо бы обобщить.

_>других Monitor кроме того одного в CLR не задумывалось, поэтому lock у нас бывает только такой, и т.д, и т.п.

(заинтересованно) А мсье может предложить другую реализацию Monitor с той же семантикой, но более эффективную? Если семантика различается — то это нифига не lock. Если не различается — надо не допиливать язык, а поменять кривой (по вашему мнению) Monitor.

Для особых эстетов есть CLR Hosting API, через который контролируется всё — от блокировок и до порождения потоков.


S>>Чисто для примера — http://phone.codeplex.com/ Спрос как бы есть (коммерческие варианты начинаются с $100 per developer per year), тем не менее проект активно развивается и допиливается аж не могу как. "Latest release date – August 15th 2013", ага.

_>Такие штуковины надо не просто выкатывать и ждать что комьюнити подхватит, а оставлять народ на развитие. Тот же ASP.NET заброшенностью не страдает, хотя уже весь в опен-сорс.
Ну так это ж классический owned opensource — у проекта есть координатор, который и несёт всю ответственность за принимаемые решения. Т.е. нифига и ни разу не "само появилось из community". Фан-сервис хорош на этапах начального сбора идей. Как только доходит до фильтрации и выбора "чем жертвуем?" конструктив сразу превращается в срач из-за отчаянной веры в "можно сделать всё и хорошо и сразу". Этот топик — наглядное подтверждение


S>>Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом
Автор(ы): Чистяков Владислав Юрьевич
Дата: 15.05.2012
В данной статье рассказывается о новом проекте языкового фрэймворка – N2
— развивать можно, но слишком скучно:

_>В смысле? Nitra это же и есть второй немерл, где ты там увидел неудобняк?
Влад поправит если что, но как я понял n2 вылез из рамок языка и это скорее убер-фреймворк на стероидах для создания dsl в промышленных масштабах. Будет очень много ломающих изменений, да и работе конца-края пока не видно.
Re[12]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 06.06.14 17:41
Оценка:
Здравствуйте, hi_octane, Вы писали:

_>Это если кроме "запустил и забыл" ничего не надо, тогда не мешает. А если хочется за задачей и всеми задачами которые она порождает протащить состояние, какую-то информацию для собственного scheduler'a, да даже, например, программер-френдли имя самой задачи и её родительской задачи + время старта каждой для логгирования — приехали.


Решать такие штуки на уровне тасков — это, имхо, микроменеджмент. Не, никто не запрещает подменять шедулер на каждой задаче (это можно сделать и сейчас, через метод-расширение), но это порождает больше проблем, чем решает. Как насчёт варианта с LogicalCallContext?

_>Ну если мне дадут в Task'х решения задач вроде этих
Автор: hi_octane
Дата: 12.10.12
, или слепить свой аналог ThreadLocal
Автор: hi_octane
Дата: 03.12.12
(ну только TaskLocal), то да, польза от самописных тасков для меня будет сомнительна. Но всегда найдётся человек которому мало решений моих задач, свои решать надо, и уже этот человек придёт на форум и будет ругаться что про него забыли


Ок, принято. Что-то подобное решал, но вспоминать надо Завтра или в понедельник поищу.

_>Да мне бы по-простому — отнаследоваться, и протаскивать буквально пару полей из таска в таск где это надо, и не протаскивать там где не надо. Человеко-дни. Ну может ещё одна-две человеко-ночи, чисто из-за того что с отладкой этого дела сложности могут быть


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


_>ну сразу хотелось бы иметь Task.CurrentTask.CancellationToken (был бы MyTask — легко), да и без него lock(ReaderWriterLock.Read(Timeout)) и т.п., при наличии ILockable вопрос решается тысячей способов. Без него — try/catch/finally и побежали — т.е. никак.

Угу. За Current.CancellationToken +1024, сам на днях в очередной раз изобретал велосипед.

_>Так и я о чём. Вместо размножения ускоспециализированных фич — дайте инфраструктуру и самую дубовую реализацию построенную на ней (без всяких internal/private для себя, и одного virtual метода для всех). А мы уж дальше сами. Например те же TaskScheduler'ы — вполне себе соответствуют этой парадигме. И вот уже пожалуйста — 20 видов типовых Scheduler'ов искаропки. Не сравнить с ThreadPool три метода на все случаи жизни, и с таймаутами вопрос решён предельно чётко


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

Ну а пилить инфраструктуру под такие задачи вслепую, без прикладной релизации... не верю, что из этого что-то хорошее выйдет. В общем, надо подкинуть идею про actor based == big thing vNext
Re: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 17.06.14 14:19
Оценка:
S>Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS (читай — лучше не рисковать и использовать для экспериментов виртуалку).

Еще можно сделать виртуалку в Windows Azure, теперь там в галерее виртуалок есть Visual Studio Professional 14 CTP с уже установленной студией.
Re[8]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 22.06.14 19:24
Оценка:
Здравствуйте, btn1, Вы писали:

B>Прям вас с Липпертом послушать — мелкософт-рабы с утра до ночи трудятся на благо студии и фичи у них как из мясорубки — лезут и лезут, делая жизнь прекраснее! Фиг-два, там сидят отъетые тюлени и тоже не особо спешат работать — ведь отговорки уже придуманы, чё париться?


Смею тебя заверить — бездельников в команде компилятора нет.

B>Нет времени? Ах вы, ***, бедненькие, в поту и крови пашете под палящим солнцем, жену-детей не видели пол-года! Так штоле? Нет. Сидят, крутят свои ж**ы в креслах, пьют кофе, рассуждают о выходных — обычная офисная работа! Нет рук? Я тя умоляю, НАЙМИ ЕЩЁ ЛЮДЕЙ, но только не индусов! Пройдёт пол-года и каждый член команды будет с лёгкостью факира выкатывать фичи.


"Некоторые менеджеры думают, что если нанять девять женщин, то можно родить ребёнка за один месяц." (c)
И, между прочим, найти и нанять разработчика компилятора высокого уровня — достаточно сложная проблема, которая уж точно не решается проверкой страны происхождения.
Re[7]: [Ann] VS14 Сtp0
От: kleng  
Дата: 22.06.14 19:27
Оценка:
Здравствуйте, Sinix, Вы писали:

S>сверхзнающих разработчиков нет


Да ладно, это вовсе не рокет сайенс. Я видел кое-какой их код в VS SDK, это лютый говнокодище, за который даже студенту должно быть стыдно.
Надо просто нанимать знающих людей, а не гномосортировщиков.
Re[8]: [Ann] VS14 Сtp0
От: Sinix  
Дата: 23.06.14 05:41
Оценка:
Здравствуйте, kleng, Вы писали:

K>Да ладно, это вовсе не рокет сайенс. Я видел кое-какой их код в VS SDK, это лютый говнокодище, за который даже студенту должно быть стыдно.


Из "Я видел косяки в A" никак не следует "B и C — отстой", это ошибка в логике.

VS SDK и компиляторы — это два сильно разных проекта. Разная ценность, разная аудитория, разные риски. Подбор специалистов соответствующий.
Re[4]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.06.14 08:29
Оценка:
Здравствуйте, btn1, Вы писали:

B>1. Читал, выставлял — бестолку. В какой-то момент ворнинги пропали, но перезапущенная студия снова разругалась.


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

B>2. Какого чёрта в свойствах проекта есть C# 6.0, но при этом нету Experimental?


Тебе нужно перевести слово experimental?

B>И наконец, если уж выкатили CTP (априори "нерабочая" среда), можно уж было поднапрячь зад и сразу создавать проекты с необходимым значением языка — CTP для того и предназначен


Нет, не только для этого. Основная цель этого CTP — понять насколько хорошо новые языковые пакеты обеспечивают совместимость, а вовсе не обкатка новых фич языка.
... << RSDN@Home 1.2.0 alpha 5 rev. 71 on Windows 8 6.2.9200.0>>
AVK Blog
Re[2]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 17:48
Оценка:
Здравствуйте, btn1, Вы писали:

B>Да ё-моё! "String interpolation" всё ещё MAY BE?!?!! Да эти клоуны и к 22 веку не напишут человеческий вывод строк!


Зачем ждать у моря погоды? Качаешь Nemerle и имеешь все плюшки плюс возможность добавить нужные тебе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 18:23
Оценка:
Здравствуйте, btn1, Вы писали:

B>Вопрос только, а зачем вообще нужен префикс??


Префиксы позволяют избежать пересечений с обычным текстом.

B>Что, старые строки нельзя "рассматривать по-новому"?


Ломать совместимость со старым кодом — это плохая идея. Префиксы же позволяют и синтаксически выделить конструкцию, и совместимость сохранить.

B>Мне нравится простота Немерли с долларом: "What's up, $name?" — это именно то, что люди просят — ПРОСТО и ЧИТАБЕЛЬНО и именно так СЕЙЧАС её надо сделать.


Согласен, но как пользователь этого решения скажу, что Разоровский подход удобнее. Лучше считать, что за $ (или другим символом) идет корректное выражение. Будет это вызов метода, идентификатор (переменная) или скобки с выражением — не важно. В неоднозначных случаях скобки помогут. Но они будут нужны очень редко.

S>>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай


B>Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.


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

С другой стороны продумать все как следует и попробовать на людях тоже надо. Это не Немерл где строковая инерполяция не более чем библиотечный макрос. Тут язык изменяется навсегда. Если сделать криво обратной дороги уже не будет (без разрыва совместимости).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Ann] VS14 Сtp0
От: kleng  
Дата: 23.06.14 18:53
Оценка:
Здравствуйте, nikov, Вы писали:

N>Создание спецификации — это первичный и отдельный процесс


Это называется водопадная модель разработки. Сначала делаем спеку, потом реализуем, и менять спеку больше не смей.
Сколько раз набивали шишки, сколько умных книг написано, что водопадная модель приводит к дерьмовому софту и раздутым бюджетам — а забеги по граблям начинаются снова и снова.
Re[14]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 19:19
Оценка:
Здравствуйте, kleng, Вы писали:

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


N>>Создание спецификации — это первичный и отдельный процесс


K>Это называется водопадная модель разработки. Сначала делаем спеку, потом реализуем, и менять спеку больше не смей.


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

Для новых фич в языке обычно выпускаются CTP и Beta версии до того, как окончательная версия спецификации зафиксирована, и у всех пользователей есть возможность отправить свой feedback, который будет учтён в процессе дизайна. Но ждать десять лет после релиза, и потом ругаться на неудачный дизайн и некомпетенцию разработчиков — это совершенно неконструктивно и бесполезно. Причём в данном случае такой дизайн не был случайностью, явным образом зафиксирован и в спецификации CLR, и в спецификации C#, и имел веские доводы в свою поддержку.

Например, кто-то может захотеть иметь строковый тип со встроенным spellchecker'ом (или хотя бы с проверкой, что указанная последовательность code units даёт валидную строку в формате UTF-16), но это выходит за рамки того, для чего предназначен тип string. Точно так же, енумы — это немногим более, чем именованные алиасы для целочисленных типов с дополнительным набором именованных констант, несмотря на то, что кому-то хочется большей функциональности.
Re[9]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.06.14 20:06
Оценка:
Здравствуйте, QrystaL, Вы писали:

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

B>>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8? _ВСЕ_, от домохозяйки до программиста, знают — вышло полное гуано с абсолютно непотребным интерфейсом. Какие продажи ждут студию?

QL>Сколько желчи


Но по сути он прав. Если новая студия не будет работать под 7-кой — это будети форменное хамство. Почему человек дожен менять ОС ради смены компилятора?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [Ann] VS14 Сtp0
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.06.14 20:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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


B>>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).

G>>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?

VD>Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".


Ну вот по такой стратегии делали async\await, с разницей в том, что это был отдельный патч. И что? Массово его использовали и был хороший фидбек?
И это при том, что семантика async\await довольно простая с точки зрения потребителя.

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

Тем более есть два фактора, которые усугубляют ситуацию для интерполяции строк:
1) Интерполяция строк не настолько ценна
2) С использованием Roslyn потенциально можно реализовать эту фичу как захочется каждому разработчику самостоятельно (или скачать готовую либу из интернета).

В результате ситуация как сейчас вполне закономерна.

G>>С VM проще, ничего не мешает иметь несколько VM внутри процесса side-by-side и даже делать прозрачный маршалинг между ними. При этом CLR4 совместим с CLR2, то есть может в свою ВМ грузить сборки под старый фреймворк, так что и на этом уровне совместимость очень тщательно поддерживается. Хотя это и не так важно.


VD>Вообще-то косяков выше крыши. Фрейморки 4.0, 4.5 и 4.5.1 не совсем совместимы. Есть куча веселых проблем. Например, программа скомпилированная через Reflection.Emit на 4.5.1 фреймворке может не запуститься под 4.0, так как типы будут прибиндены так как они лежат в 4.5.1 сборках.

VD>Было большой ошибкой делать 4.5.* фреймворки обновлениями для 4.0. Так что с совместимостью у донете все не очень хорошо.
VD>Про приседания с версиями сборок я вообще молчу.
А никто не говорит то N+1 версия должна быть совместима с N. Важно чтобы N была совместима с N+1.




G>>Посмотри на Java, недавно вышла Java 8, а я знаю людей, которые людей до сих пор используют Java 6 (2006 год), а некоторые до сих пор используют Java 1.4. При этом с совместимостью у Java не сильно хуже, чем у C#.

VD>Я знаю не мало людей которые не могли перейти с одной версии фреймворка на другую. Это не аргумент. В Яве все примерно тоже самое. Кто по шустрее переходит. Кто по осторожнее тормозит с переходом.
Я тоже знаю, но это чисто политическое решение, а не техническое. Например в одном банке очень долго не хотели ставить .NET 4 на клиентские машины и софт, который пилили подрядчики, вынужден был работать на .NET 3.5 чуть ли не до начала 2014 года. Хотя раскатать .NET по всей компании с помощью политики займет 20 минут работы и неделю подождать когда все компы перезагрузятся.
Re[16]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 23.06.14 21:17
Оценка:
Здравствуйте, kleng, Вы писали:

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


N>>Спеку можно поменять. Но порог изменений для уже выпущенного продукта очень высокий из-за требований обратной совместимости


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


Какой смысл обсуждать это по отношению к фиче, которая задизайнена, реализована и стандартизована уже более 10 лет назад? Видимо, были какие-то прототипы в то время. Ты посылал свой feedback? Что тебе ответили? С чем ты несогласен?
Re[8]: [Ann] VS14 Сtp0
От: _NN_ www.nemerleweb.com
Дата: 24.06.14 07:44
Оценка:
Здравствуйте, VladD2, Вы писали:

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


B>>>Для начала нужно реализовать хотя бы это в качестве экспериментальной фичи (как сейчас с conditional access).

G>>Увы в C# такое невозможно. Можно сделать отдельный язык, как в свое время Cω (в котором тестировали Linq), или Axum (в котором тестировали async\await). Только вы реально ими пользовались?

VD>Чёйто не возможно? Очень даже возможно. Добавили ключик компилятора включающий фичу и написали в документации — "Фича эксперементальная. Использование на свой страх и риск. В будущих версиях может быть удалена. Голосовать за или против фичи по такому-то адресу.".


Так ведь сделали ключиком

Автор: nikov
Дата: 23.06.14
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[12]: [Ann] VS14 Сtp0
От: KRT Украина  
Дата: 24.06.14 10:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>То что пропал способ открыть папку приложения в стартовом меню и посмотреть какие файлы в него входят — это вообще ужасно неудобно. Форменная деградация.


Если речь идет об обычных приложениях (не метро), то можно открыть папку. Правый клик по приложению > Открыть расположение файла
Re[9]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 15:52
Оценка:
Здравствуйте, nikov, Вы писали:

N>Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке?


Не думаю. Но прошло уже 5 лет как пилится Рослин (я не ошибаюсь?). Можно было такую мелочь и реализовать. Фича мелкая, но очень удобная. Плюс вау-эффект. Учитывая, что ты сам говоришь, что работы велись, не ясно что могло привести к решению их остановить.

N>Между прочим, Roslyn — это open source библиотека. Ты можешь реализовывать фичи и посылать пул реквесты.


Ну, Nitra тоже теперь опен-сорс. Так что ты тоже можешь нам помочь.
Сам понимаешь, у нас тоже объем работ большой, а команда сильно меньше вашей.
В прочем, я может и потратил бы время если бы был уверен, что время не будет потрачено зря. Но судя по тому что вы и свою реализацию выкинули вряд ли на это можно надеяться.

N>В Nemerle работает Extract Method рефакторинг с интерполированными строками? А с частью выражения после $ в интерполированной строке?


В немерле вообще нет Extract Method. Не было кому запилить. Но тот же рефакторинг переименования работает и внутри сплайсов. Extract Method просто запретить работать в условиях когда выделение пересекает границы сплайсов. Допускать рефакторинг только внутри одного сплайса или вне $-строки.

N>Видишь, все эти пункты требуют принятия каких-то решений.


В любой работе нужно постоянно принимать решения. В дизайне — это основная задача. Кто же спорит то. Но за 5 лет то уж можно было потратить некоторое время на дизайн. Тем более, что вы не с нуля фичу делаете, а повторяете имеющуюся не в одном языке. Если есть сомениния — обращайтесь к нам (немерлистам). Мы с радостью расскажем о проблемах и путях и возможного обхода.

N>И это не может быть сделано одним человеком, так как человеку свойственно ошибаться. И мы не можем потом поломать код у тысяч разработчиков, потому что какое-то решение было неудачным и нуждается в исправлении. А неудачные (или даже в чём-то спорные решения) приведут к тому, что люди потом будут ругать Microsoft десятилетиями (см. этот тред выше).


Парень тут дело сказал. Да и ты правильную мысль на счет пул-реквеста высказал. Если это теперь опен-сорс, то можно сделать отдельный клон и там запилить фичу. Потом выдать народу пробную версию на тестирование и устроить опрос. Забросить на РСДН и Стек оверфлоу. Будет вам фитбек в лучшем виде.

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

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

В общем, если нужно могу помочь идеями. На реализацию вряд ли время смогу выкраить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 15:53
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Так ведь сделали ключиком


Я говорил о том, что можно было бы сделать ключ конкретно для этой фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 15:59
Оценка:
Здравствуйте, nikov, Вы писали:

N>http://blogs.msdn.com/resized-image.ashx/__size/550x0/__key/communityserver-blogs-components-weblogfiles/00-00-00-33-48/3884.cslv.png


Как я понял даже при включении эксперементальных фич их понимает только компилятор. Почему их не понимает лэнгвидж-сервис? Как я понял весь смысл Рослина в том, что он переиспользует и для компилятора, и для лэнгвидж-сервиса один и тот же код. Я что-то не так понял?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 16:22
Оценка:
Здравствуйте, nikov, Вы писали:

N>Это не так. Реализация абсолютно правильная, и в точности соответствует международно принятой спецификации.


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

Сейчас уже менять спки поздно. Слишком много кода использует особенности энумов.

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

Сейчас кода у вас есть Рослин было бы разумно начать работу над алгеброическими типами и паттерн-матчингом.

Еще одна интересная тема — это объеденение и пересечение типов. Ее можно отлично совместить с алгеброическими типами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.06.14 16:34
Оценка:
Здравствуйте, KRT, Вы писали:

KRT>Если речь идет об обычных приложениях (не метро), то можно открыть папку. Правый клик по приложению > Открыть расположение файла


Как я понимаю, расположение файла — это не то. Если у меня шорткат, то "расположение файла" приведет меня в папку где находится файл на который ссылается шорткат. А мне нужно в папку где лежит шорткат.

Да и вообще — это не правильно, что исчезла привычная и удобная функциональность. А ведь куча продуктов рассчитывает на нее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [Ann] VS14 Сtp0
От: fddima  
Дата: 24.06.14 22:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В немерле вообще нет Extract Method. Не было кому запилить. Но тот же рефакторинг переименования работает и внутри сплайсов. Extract Method просто запретить работать в условиях когда выделение пересекает границы сплайсов. Допускать рефакторинг только внутри одного сплайса или вне $-строки.

+1. Я не так давно начал пользовать extract method очень по чуть-чуть (скорее ради интереса). Оно вроде и удобно, но честно говоря с помощью copy-paste можно добиться того же самого, за тоже самое время — один фиг потом нужно причесывать метод. Поэтому — лично моё мнение — нет — и не надо. Самый главный рефакторинг который вообще существует — это rename всего чего угодно. Остальное — иногда полезно и весьма на любителя. И уж точно если сначала думать а потом писать — extract method и подобное — глупости. Иначе говоря — на мой взгляд — фича ради фичи.
Re[6]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:04
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как я понял даже при включении эксперементальных фич их понимает только компилятор. Почему их не понимает лэнгвидж-сервис? Как я понял весь смысл Рослина в том, что он переиспользует и для компилятора, и для лэнгвидж-сервиса один и тот же код. Я что-то не так понял?


Действительно, и в компиляторе, и в language service для базовой поддержки языковых фич (т.е. не считая специальные возможности в intellisense, рефакторингах и т.д.) должен работать один и тот же код (те же самые методы в тех же сборках) — одна и та же логика не должна быть реализована в разных местах. Но теоретически можно подсунуть разные версии сборок для компилятора и для language service. Но если такое происходит в CTP — то это странный баг. Я не наблюдаю этого на последних ночных билдах, установленных на моей машине. Попробую разобраться, что там происходит в CTP...
Re[10]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 25.06.14 01:24
Оценка:
Здравствуйте, VladD2, Вы писали:

N>>Ты думаешь, это единственная фича, которой мы занимаемся? Или это самая важная фича в языке?


VD>Не думаю. Но прошло уже 5 лет как пилится Рослин (я не ошибаюсь?). Можно было такую мелочь и реализовать. Фича мелкая, но очень удобная. Плюс вау-эффект. Учитывая, что ты сам говоришь, что работы велись, не ясно что могло привести к решению их остановить.


То, что есть более приоритетные мелочи. Есть баги, которые необходимо пофиксить. Есть перформанс проблемы, которые надо решать. Есть огромная работа по переводу всей студийной функциональности на Roslyn. Есть новые студийные фичи, которые требуют определённых API со стороны Roslyn.

VD>Но судя по тому что вы и свою реализацию выкинули вряд ли на это можно надеяться.


Мы ничего не выкидывали. Есть неоконченый дизайн и прототип, который совершенно не production quality.

VD>Что до решений, то решения всегда принимает один человек. Коллективное принятие решений не бывает.


Language design team принимает решения коллегиально. Я не знаю случая, когда дизайнеры расходились по каким-то вопросам, и вместо урегулирования этих вопросов кто-то один в приказном порядке зафиксировал какое-то решение.

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


Спасибо, идеи очень хорошие, мы постараемся их учесть. Но они ещё раз демонстрируют, что дизайн этой фичи не является однозначным и тривиальным.
Re[11]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.06.14 10:07
Оценка:
Здравствуйте, nikov, Вы писали:

N>Мы ничего не выкидывали. Есть неоконченый дизайн и прототип, который совершенно не production quality.


А на него можно как-то посмотреть?

N>Спасибо, идеи очень хорошие, мы постараемся их учесть. Но они ещё раз демонстрируют, что дизайн этой фичи не является однозначным и тривиальным.


Никакой дизайн не является однозначным. На то он и дизайн. Все можно сделать по разному.

В данном случае не нужно изобретать велосипед. Нужно просто воспользоваться чужим опытом. Ну, и не делать вселенский всемогутер, как тут некоторые предлагают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [Ann] VS14 Сtp0
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.06.14 08:22
Оценка:
Здравствуйте, nikov, Вы писали:

N>Действительно, и в компиляторе, и в language service для базовой поддержки языковых фич (т.е. не считая специальные возможности в intellisense, рефакторингах и т.д.) должен работать один и тот же код (те же самые методы в тех же сборках) — одна и та же логика не должна быть реализована в разных местах. Но теоретически можно подсунуть разные версии сборок для компилятора и для language service.


Я думаю дело не в разных сборках, а в том что LangVersion на lang service не влияет и он по прежнему работает в рамках C# 5.
... << RSDN@Home 1.2.0 alpha 5 rev. 100 on Windows 8 6.2.9200.0>>
AVK Blog
Re[21]: [Ann] VS14 Сtp0
От: Tom Россия http://www.RSDN.ru
Дата: 26.06.14 10:03
Оценка:
N>Работа ведётся, уже довольно давно. Возможно, вскоре появится прототип в open репозитории.
Во во во, палегче!
Это смахивает на next big thing в C# языке!
Народная мудрось
всем все никому ничего(с).
Re[13]: [Ann] VS14 Сtp0
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.06.14 12:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Где ты искал то? Потому что на skype.com жмем кнопку Get Skype и попадаем сразу на страницук Skype for Windows desktop.


Возможно они что-то поменяли. Раньше чтобы найти ссылку для скачивания нужно было исакать в гугле и "Skype for Windows desktop". А что бы это сделать сначала нужно было знать что именно это нужно искать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: [Ann] VS14 Сtp0
От: nikov США http://www.linkedin.com/in/nikov
Дата: 02.07.14 03:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Кстати, Nemerle позволяет использовать строковые литералы внутри interpolated выражений?
Re[22]: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 08.08.14 08:09
Оценка:
N>Черновик дизайна
N>Обсуждение на CodePlex
N>Публично доступного кода пока нет, ожидается через пару недель

А дженерики можно будет использовать?
Re[24]: [Ann] VS14 Сtp0
От: Qodomoc Россия  
Дата: 15.08.14 10:10
Оценка:
А что-нибудь такое можно будет:
case List<T> where T : ISmth:
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.