Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS (читай — лучше не рисковать и использовать для экспериментов виртуалку).
Из того, что точно будет интересно пощупать — интегрированный в VS roslyn compiler + c# 6 со всеми плюшками типа someVal?.ToString() ?? "".
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.
Здравствуйте, Sinix, Вы писали:
S>visual-studio-14-ctp
Может я чё не понимаю... она что, ТОЛЬКО НА ВОСЬМЁРКЕ РАБОТАЕТ??? Только что попробовал поставить на Win7 SP1 — "нужна новая версия винды"! Куда новее-то? Или они восьмёрсу тоже "виндой" считают??
Здравствуйте, 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#.
Здравствуйте, 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>Не понимаю терминологии. О чём речь?
S>>* Как обрабатывать такие штуки в expression tree-лямбдах и в dynamic? B>Надо смотреть конкретный пример — ни то, ни другое не используется широко в программах и поэтому вопрос, нужно ли вообще там что-то поддерживать.
Угу, т.е. форматирование строк ресурсов и динамический sql в orm-провайдерах тоже идут лесом, т.к. не нужны(tm).
Получается, делать interpolated string особого смысла нет. Можно хоть один пригодный для продакшна пример?
S>>Причём каждый из ответов перекидывает фичу в треугольнике время-затраты-полезность из угла в угол. Выбирай
B>Да ничё он не перекидывает! Тут же классическая проблема дилетантов: хочется изобразить что-то умное и начинаются вымусоливания граничных случаев и маразматических применений. Зачем? Просто пропарси строку, затем string.concat значений. Всё.
)) Начнём с того, что string.concat должен применяться только если не задано форматирование, $"Money {modey:N2}" через concat не сделаешь. Закончим тем, что в вашем варианте покрывается процентов 10 от возможных вариантов использования, причём остальные 90 в будущем не могут быть реализованы из-за подхода "чо там думать, кодить надо"
Здравствуйте, 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>>
. Эта штука ущербна по определению. И Эрик Липперт уже ушёл, а ничего в головах людей работающих над компилятором C# не изменилось
Поднимать вопрос за вопросом можно до бесконечности, но если отойти на шаг выше, и добавить добавить Compile-Time String Formatter класс, использующих API Roslyn и контекст где описана строка — он сам построит дерево вызовов ToString для аргументов и подсунет текущую культуру, текущий форматтер и т.п. Плюс открытая реализация чтобы его можно было подменить/расширить, и тогда базовый вариант будет доступен всем, а на кодеплексе сами размножатся самые нетривиальные форматтеры, от поддерживающих абсолютно все фичи которые там обсуждаются + те до которых мы никогда не додумаемся.
Здравствуйте, 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) — тоже неплохо оптимизирует код! Чо, опять будем сидеть на заплесневелом интыпрайзе? А теперь вообще всех накрыло мобильным пузырём — облака, тонкие клиенты и т.п. Ну и что, нужны тебе эти датасеты? Да ради бога, но это никак не помешает тысячам компаний купить новый, НЕСОВМЕСТИМЫЙ язык и сделать тебя как стоячего — просто уже в силу новых парадигм, а не только фич языка.
Ну как, убедил?
Здравствуйте, AndrewVK, Вы писали:
AVK>Только со стороны студии поддержки никакой, увы. Все новые конструкции отображаются как ошибки и ломают интеллисенс. И надо ручками задать <LangVersion>Experimental</LangVersion> в файле проекта.
Угу, спасибо за поправки! Мопед не мой, у самого руки пока не дошли поставить.
Здравствуйте, 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). И даже для такой мелочи нужно рассмотреть тонну вопросов, т.к. потом решение поменять будет слегка поздновато.
С вашим вариантом фичу надо ждать ближе к седьмому шарпу
Здравствуйте, 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 не умеет {перечисление всякой лабуды, до которой автору не было раньше дела}". Вернись к абзацу с "дильдо" — он всё объясняет.
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 выйдет
B>Я не корю их за то, что такую тривиальщину не сделали до этого (хотя и могли). Я не понимаю, почему сейчас это отнимает столько времени!? Ты ж прогер, просто сядь за листок и набросай псевдокод — да там от силы 20 строк получится!
Всё просто — MS не получает денег за добавление новых фич. Они получают деньги за переход старых клиентов на новую версию и приманивание новых клиентов старыми. Выше
я написал примерный расклад по количеству пользователей и по тому, как ломающие изменения сказываются на доходах.
По большому счёту, абсолютно неважно, сколько времени и ресурсов займёт та или иная фича, МС может позволить себе держать заготовки в инкубаторе годами до их промышленного применения. Но добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка. Иначе язык или быстро превратится в помойку, которую не ругает только ленивый, или так и застрянет в качестве языка для фанов. Подтверждающих примеров сколько угодно, обратных я что-то не припомню.
В c# team это правило действовало буквально с начала разработки языка. И буквально с первых дней разработчиков "вежливо" спрашивали "где моя любимая фича?!! c# — отстой!!! вы дибилы!!!". Тема обсуждалась сотни раз, вот и вот самые популярные объяснения. Тем не менее, люди отказываются верить, что таких вопросов на каждой итерации всплывает сотни, что сделать каждый из них нужно только за счёт других фич, и что большую часть каждого релиза занимают "мажорные" фичи, на которые сделана стратегическая ставка и затрагивать их нельзя вот никак. Совсем.
Даже про "20 строк кода" отвечалось неоднократно. Рекомендую вот эту классику.
B>Ну так в чём твоя ирония по поводу "великого btn1" и лопухов, которые даже занимаясь вплотную компилятором, не просекли вовремя абсолютную идентичность начальных фаз компиляции для собственно компилятора и подсветки??
Ну... за иронию извиняюсь, но тема действительно классическая. С одной стороны тонны обстоятельных доводов, пара десятков статей от самих разработчиков языка, выкладки с цифрами и т.д. и т.п. С другой, неизменно, люди которые лучше разработчиков знают как должен выглядеть шарп и чего это будет стоить Со стороны всё действительно просто. Копнёшь — лучше и не вкапываться было.
Маленький пример — экспансивное развитие шарпа привело к тому, что, например компиляция каждого метода выполнялась в ~26 проходов (это до async/await и без учёта некоторых оптимизаций). Т.е. добавлене каждой новой фичи (пусть и "в 20 строк") ещё ненамного замедляло общее время компиляции и добавляло минусов в копилку следующих фич — для них порог добавления становился ещё выше. С выходом рослина это конечно не так актуально, тем не менее надо понимать, что стоимость добавления любой мелочи зависит не столько от её размера в коде, сколько от её влияния на экосистему шарпа в целом.
Да, с рослином порог для мелочей значительно понизился и со временем подобных плюшек станет больше. Тем забавней претензии "чож вы сразу шестой шарп не написали, а начали с 1.0?".
B>Я не хочу хвалиться, но связь тут очевидна и то, что это не было сделано даже таким гигантом как M$, говорит лишь о том, что и там не боги компиляторы обжигают — такие же спецы как мы с тобой (если не хуже). А пипец всей ситуации во вранье, которое эти ламеры впаривают нам как "обоснование отказа", хотя фактически оправдывают свою лень и тупость.
Смотри как парадоксально. Есть компании, которые закрыты донельзя, никогда не рассказывают о внутренностях продуктов, обучение проводят за неиллюзорные бабки, но при этом массовый мейнстримный рынок так и не заняли. Oracle, axapta (пока она ещё была, конечно), SAP, crytek (до недавнего времени) — в каждой области есть такие примеры. А есть компании, сотрудники которых забесплатно выкладывают в веб проблемы разработки под рынок в полмиллиона весьма привередливых клиентов и, главное, учат с подобными проблемами бороться.
Первые очень ценятся — типа, элита и локомотивы Вторые, понятное дело ламеры, т.к. не слушают своих благодарных фанов.
Наверно, во всём этом есть какая-то логика и мораль, но я её пока не нашёл.
Здравствуйте, 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
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.
Кстати, про "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>Ну, удачи им Главное чтоб не получился неудобняк как с вторым немерлом
Здравствуйте, 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. Это просто грязная политика
(по-моему, даже Turbo C не подсвечивал кода!)
Главное чтоб не получился неудобняк как с вторым немерлом