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

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

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

Здравствуйте, 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?
* Как насчёт динамических строк, например, строк из ресурсных сборок?

ну и тд и тп.

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

Здравствуйте, 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 значений. Всё.

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

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

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

Ответ на вопрос "зачем" — совместимость. Крайне необходимо чтобы 99,9999% существующих программ не поломались при введении новой фичи. Кроме того важно чтобы в дальнейшем, при необходимости фичу допилить, изменения не поломали 99,9999% существующих программ.

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

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

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

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

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

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

Здравствуйте, 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#.

Здравствуйте, 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) — тоже неплохо оптимизирует код! Чо, опять будем сидеть на заплесневелом интыпрайзе? А теперь вообще всех накрыло мобильным пузырём — облака, тонкие клиенты и т.п. Ну и что, нужны тебе эти датасеты? Да ради бога, но это никак не помешает тысячам компаний купить новый, НЕСОВМЕСТИМЫЙ язык и сделать тебя как стоячего — просто уже в силу новых парадигм, а не только фич языка.
Ну как, убедил?

Здравствуйте, 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#.

Я знаю не мало людей которые не могли перейти с одной версии фреймворка на другую. Это не аргумент. В Яве все примерно тоже самое. Кто по шустрее переходит. Кто по осторожнее тормозит с переходом.

Здравствуйте, 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 в будущем не могут быть реализованы из-за подхода "чо там думать, кодить надо"

Здравствуйте, 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 не умеет {перечисление всякой лабуды, до которой автору не было раньше дела}". Вернись к абзацу с "дильдо" — он всё объясняет.

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


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

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

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

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

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

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

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


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

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

Наверно, во всём этом есть какая-то логика и мораль, но я её пока не нашёл.

Здравствуйте, 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. Это просто грязная политика

Здравствуйте, 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 такие идиоты, в одном месте фичу с горем пополам приделали, а про остальные очевидные места, с которыми она связана, как всегда забыли...)

Здравствуйте, 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?

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

Здравствуйте, 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
Это только для наших рекурсивных строк. Привел именно их, так как гитхаб не умеет искать на $".

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

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

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

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

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

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

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

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

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

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

С другой стороны продумать все как следует и попробовать на людях тоже надо. Это не Немерл где строковая инерполяция не более чем библиотечный макрос. Тут язык изменяется навсегда. Если сделать криво обратной дороги уже не будет (без разрыва совместимости).

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

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

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

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

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

_>4 года назад мы спорили о микроменеджменте фич языка. Эта штука ущербна по определению. И Эрик Липперт уже ушёл, а ничего в головах людей работающих над компилятором 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). И даже для такой мелочи нужно рассмотреть тонну вопросов, т.к. потом решение поменять будет слегка поздновато.

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

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 выйдет

Здравствуйте, 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 выйдет
Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом — развивать можно, но слишком скучно:

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

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>Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом — развивать можно, но слишком скучно:

В смысле? Nitra это же и есть второй немерл, где ты там увидел неудобняк?

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

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

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

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

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

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

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

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

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

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

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

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

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

По форуму это видно, ага.

Здравствуйте, 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 (скоро появятся, пока в альфа-версии). Тогда люди смогли бы для себя сами нужные реализации сделать. Причем на альтернативной основе.

Но МС в свой дизайн подобную гибкость не закладывает. Даже в Рослине все гвоздями будет прибито (похоже).

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

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

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

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

S>visual-studio-14-ctp

Может я чё не понимаю... она что, ТОЛЬКО НА ВОСЬМЁРКЕ РАБОТАЕТ??? Только что попробовал поставить на Win7 SP1 — "нужна новая версия винды"! Куда новее-то? Или они восьмёрсу тоже "виндой" считают??

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

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

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

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

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

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

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

Интересно, что в CTP пока приходится писать так:

Customer?.Order?.ShipDate?.Year

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

Вопрос залу: кто-нибудь ставил ЭТО? Я водрузил студию на виртуалку, создал проект, проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")

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

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

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

Здравствуйте, 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 через свойства проекта — тоже бестолку.
И опять возвращаемся к вопросу о жадности: сколько можно экономить на индусах и выкатывать откровенный отстой?

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

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

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

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

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

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

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

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

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

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



Я понимаю, что это CTP, но почему-то на выходе у мелкософта получается WTF.

Здравствуйте, 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.

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

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

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

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

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

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

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

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

Я думаю дело не в разных сборках, а в том что LangVersion на lang service не влияет и он по прежнему работает в рамках C# 5.

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

Еще можно сделать виртуалку в Windows Azure, теперь там в галерее виртуалок есть Visual Studio Professional 14 CTP с уже установленной студией.

Вышел CTP3.
Подробности здесь и здесь.

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