Здравствуйте, btn1, Вы писали: B>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8? _ВСЕ_, от домохозяйки до программиста, знают — вышло полное гуано с абсолютно непотребным интерфейсом. Какие продажи ждут студию?
Здравствуйте, QrystaL, Вы писали:
QL>Сколько желчи
Желчь?? В простой констатации факта, что Win8 — это epic fail? Ну извини, я не знаю, какие ещё слова подобрать к полному провалу. Может, "альтернативный успех"?
Вопрос залу: кто-нибудь ставил ЭТО? Я водрузил студию на виртуалку, создал проект, проверил фичи — using System.Console; работает, остальное — нет! (язык проекта выставлен "C# 6.0")
Здравствуйте, 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, ранние версии которого не понимались между локализациями (или я брешу?). По моему — не понимались.
Здравствуйте, hi_octane, Вы писали:
_>В крупных проектах несколько разных штуковин для одного и того же появляются, чаще всего, как следствие сохранения обратной совместимости при выкатывании новых версий. А тут — им реально в VS 2002 были нужны VB.NET, C# и они сходу запилили собственно компиляторы, студийный парсер для Intellisense, CodeDom и (судя по отличиям в поведении) ещё и отдельный какой-то парсер для отладчика. Мне что-то не верится что, например лично ты, пошёл бы таким-же путём в первой же версии продукта
Насколько помню, из действительно независимых реализаций был только CodeDom и аналогичная SolutionModel для VS. Парсеры в VS хоть и отличались, но пилились на основе кода компиляторов. Учитывая, что vs team, c# team и vb team в то время не были объединены в одну команду, объём работы и общее непонимание, что из этого выйдет — и так неплохо.
S>>Других популярных managed-языков у MS для нас нет, так что что ещё, начиная с первого релиза нужно было подсадить на roslyn, мне решительно непонятно _>Ага. Других тасков кроме тех которые в System.Threading.Tasks у нас нет, так что async/await расписываются только в то во что расписываются
Пхе, ну сколько можно гнать откровенную пургу? Найди вот тут
Task в кастомном awaiter плиз, а потом рассказывай про "нет и нельзя".
Давай ещё возмущаться, что linq без enumerable не работает (хотя этоне так от слова абсолютно, т.е. совсем).
Кстати, Липперт перед уходом из MS намекал, что идею с syntax pattern неплохо бы обобщить.
_>других Monitor кроме того одного в CLR не задумывалось, поэтому lock у нас бывает только такой, и т.д, и т.п.
(заинтересованно) А мсье может предложить другую реализацию Monitor с той же семантикой, но более эффективную? Если семантика различается — то это нифига не lock. Если не различается — надо не допиливать язык, а поменять кривой (по вашему мнению) Monitor.
Для особых эстетов есть CLR Hosting API, через который контролируется всё — от блокировок и до порождения потоков.
S>>Чисто для примера — http://phone.codeplex.com/ Спрос как бы есть (коммерческие варианты начинаются с $100 per developer per year), тем не менее проект активно развивается и допиливается аж не могу как. "Latest release date – August 15th 2013", ага. _>Такие штуковины надо не просто выкатывать и ждать что комьюнити подхватит, а оставлять народ на развитие. Тот же ASP.NET заброшенностью не страдает, хотя уже весь в опен-сорс.
Ну так это ж классический owned opensource — у проекта есть координатор, который и несёт всю ответственность за принимаемые решения. Т.е. нифига и ни разу не "само появилось из community". Фан-сервис хорош на этапах начального сбора идей. Как только доходит до фильтрации и выбора "чем жертвуем?" конструктив сразу превращается в срач из-за отчаянной веры в "можно сделать всё и хорошо и сразу". Этот топик — наглядное подтверждение
— развивать можно, но слишком скучно: _>В смысле? Nitra это же и есть второй немерл, где ты там увидел неудобняк?
Влад поправит если что, но как я понял n2 вылез из рамок языка и это скорее убер-фреймворк на стероидах для создания dsl в промышленных масштабах. Будет очень много ломающих изменений, да и работе конца-края пока не видно.
Здравствуйте, btn1, Вы писали:
S>>Всё просто — MS не получает денег за добавление новых фич. B>Если говорить о деньгах, получается мелкософт прямо облизывает своих клиентов "какие фичи вы хотите в следующем релизе? Ведь вы заплатили за студию — имеете право!" — так штоле?
А вот не надо выцеплять фразы из контекста напрямую и додумывать
Перечитай предыдущий пост, там смысл по-моему очевиден: MS не получает денег напрямую с новых фич, максимум пользы от них — приманить новых клиентов. Куда важнее не потерять старых.
Ты в принципе написал то же самое, только ещё раз макнул MS в говно, так как они не делают то, что нравится тебе. Надо заметить, конструктива топику это не добавляет
Офф: тем не менее, MS очень внимательно стала относиться к поддержке со стороны community. От голосовалок на uservoice и до принятия сторонних коммитов в код asp.net/ef.
S>>... добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка. B>А как тут измеряется ВЫЙГРЫШ? Количество эндорфина на куб.см. мозга юзера? Количество продаж студии? Громкость хлопков при анонсе фичи? Я не понимаю, как можно "проигрывать" там, где ты тупо делаешь язык лучше!
Офф 2, grammarnazi, не вам лично: выИгрыш Мозайка йз войнов андройда блйн!
Понятно, что опечатка по Фрейду, но достало уже. Хуже чем "ться", там хоть понятно откуда ошибка. А вот как можно засунуть й куда не лезет — эт для меня загадка
Уже писал выше, давай ещё раз. Проиграть можно очень легко: запороть новой фичей возможность расширения языка, сделать фичу так, что её легче использовать неправильно, чем правильно, поломать совместимость. Пример врождённых косяков есть у любого языка, c# не исключение. Другое дело, что доля этих косяков — 0.01, а не 200% (да-да, js, я говорю про тебя!)
B>Фичи можно как-то сравнить по полезности, но извини, что-то я не припомню никаких революций в мире C#, сильно облегчающих мне жизнь. Зато кучи маленьких, но необходимых вещей так и померли под отговорками тех, кто говнокодил до "эпохи Рослина".
Тоже писалось выше. Выбор у разработчиков до недавнего времени был не "добавим финтифлюшку/не добавим" а "успеваем выпустить всё, что обязательно должно быть к текущей итерации/не успеваем".
B>Ну вот, скажем, инициализация автопроперти — что, дюже прорывная фича?
На мой взгляд, на практике полезна разве что для скриптов и прочих поделок. Добавляем валидацию параметров в конструктор (или вы в каждый класс что попало суёте?) и всё удобство моментально идёт лесом.
Но ок — что надо было перекинуть на другой релиз ради набора подобных мегафич? Генерики? linq? await? dlr? Или как всегда, должна быть магия и все фичи должны добавляться бесплатно?
B>...и правильно делают! Потому что деньги — не вопрос, специалистов — море, но M$ всё равно продолжает "кидать" юзеров. Нет времени? Ах вы, ***, бедненькие, в поту и крови пашете под палящим солнцем, жену-детей не видели пол-года! Так штоле? Нет. Сидят, крутят свои ж**ы в креслах, пьют кофе, рассуждают о выходных — обычная офисная работа! Нет рук? Я тя умоляю, НАЙМИ ЕЩЁ ЛЮДЕЙ, но только не индусов! Пройдёт пол-года и каждый член команды будет с лёгкостью факира выкатывать фичи. Или опять... "жадность"? Вот то-то же!
Ненависть-скандалы-интриги-расследования — эт в flame.comp и в прочие мусорные ветки плиз, промахнулись окошком Ещё, очень советую поработать хоть раз в жизни хотя бы с мааленьким коллективом на 15-20 человек, фантазии про "девять женщин выносят ребёнка за месяц" сразу пропадут.
B>Про коммерцию не надо — она не подвержена математической логике, как непостижимо то, что ГовноDOS вдруг выйграл у CP/M. Это просто грязная политика
Ну, это эльфизм. Игнорировать реальность не надо, больно бьёт по носу. Ты сам выше привёл такой пример: одновременно требуешь от MS
Я хочу здесь и сейчас, пусть ценой неудобств, возможность _новый_ код писать на _новом_ языке. Повторюсь: "мэйнстрим" никто никуда не тащит, пусть сидит на FW 2.0 и лелеет свои мегабайты суперкода.
и, когда они делают ровно то, что просил, возмущаешься
каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8?
(если что, проблема скорее всего в win7 без обновлений. У ранних ctp vs2013 те же проблемы были).
Здравствуйте, btn1, Вы писали: B>Может, "альтернативный успех"?
Пользуюсь с первых дней, после апдейта 8.1.1 стало практически неотличимо от 7.
В продажах может и провал, а в остальном — проблем нет
_>>Ага. Других тасков кроме тех которые в System.Threading.Tasks у нас нет, так что async/await расписываются только в то во что расписываются
S>Пхе, ну сколько можно гнать откровенную пургу? Найди вот тут
То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями. Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался? Вот я как рефлектор первый раз на async ещё CTP открыл, так сразу и понял — косяк. Масштаб косяка понял сильно позже, когда первые scheduler'ы писать пришлось. Но там же люди поумнее сидят, а такой хардкод в релиз почему-то пустили.
S>Давай ещё возмущаться, что linq без enumerable не работает
Про линк я ничего не говорил. Как раз наоборот удивляюсь как они догадались его почти нормальным сделать.
S>(заинтересованно) А мсье может предложить другую реализацию Monitor с той же семантикой, но более эффективную? Если семантика различается — то это нифига не lock. Если не различается — надо не допиливать язык, а поменять кривой (по вашему мнению) Monitor.
А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции. А вообще интерфейс ILockable и возможность лочить через него, либо вызывать Monitor если он не поддерживается. Заодно искаропки решилась бы проблема с тем что asnyc/await с локами смешивать нельзя.
S>Влад поправит если что, но как я понял n2 вылез из рамок языка и это скорее убер-фреймворк на стероидах для создания dsl в промышленных масштабах. Ну дык Влад пошёл абсолютно правильным путём — обобщил понятие dsl и макросов, пришёл к пониманию что сам Nemerle вполне dsl и тоже выражается через набор макросов и средства описания типов которыми макросы оперируют. Плюс выкатил абсолютно новую идею что компиляция вообще может быть описана как макро-преобразования с одного dsl в другой, аж до бинарного кода. Вот тебе и n2 — фреймворк и язык в одном флаконе.
S>Будет очень много ломающих изменений, да и работе конца-края пока не видно.
За такую идею я бы сам пару репозиториев поломал, просто из солидарности Тут главное что прогресс виден.
Ну, могу или там плюсик убрать или тут извиниться. Выбирай
Если серьёзно, на практике всё не так, как в теории. Внезапно оказывается, что "хардкод await на Task" ничему не мешает. Точно так же, как хардкод yield return на IEnumerable<>.
_>То что await можно сделать на что угодно это нормально сделанные пол-дела. Теперь покажи мне async с чем-то кроме Task. Там внутри неонка получается конечный автомат, на базе AsyncMethodBuilder, который предельно захардкожен, причём, в отличии от автомата который делает yield, на классы с реализациями.
При желании хардкод заменяется на IAsyncStateMachine и IAsyncMethodBuilder, т.е. в будущем никто не запретит добавить в INotifyCompletion
и извращаться как заблагорассудится. На практике смысла в этом не больше, чем в замене итератора для yield return. Посмотри внутренности дефолтного AsyncMethodBuilder, там весь функционал по большому счёту сводится к m_Task.SetResult. Не, при большом желании можно переписать таск с 0 (где-то пара человекомесяцев минимум), но зачем — мне решительно непонятно. Разве что чтобы возмущаться "опять используют велосипед вместо готового решения"
_>Самое дубовое решение сделать чтобы метод мог возвращать любой MyTask<T> : Task<T> с какими-то доп полями, или даже IAwaitable<T>, способный, например, ещё и настройки какие-то scheduler'у передать — почему никто не догадался?
Потому же, почему нельзя вернуть IMyEnumerable<T> из кастомного итератора — во, первых, фичу никто не спроектировал, не закодил, не протестировал и не отправил в продакшн. Во-вторых, идея на корню рубится типовыми сценариями использования. Для IEnumerable это linq, для async — await. Как через них будешь свой чудо-тип протаскивать?
Только не надо начинать "вот у MS разработчики есть, пусть они и думают". Они как раз думают перед тем, как делать, поэтому шарп практически не страдает от избытка преждевременных фич.
S>>Давай ещё возмущаться, что linq без enumerable не работает _>Про линк я ничего не говорил. Как раз наоборот удивляюсь как они догадались его почти нормальным сделать.
Тем не менее, принципы 1-в-1, даже код для разворачивания await и yield частично общий.
_>А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции.
Ну ок, можно попросить чтоб в следующей версии добавился
ILockable { bool TryEnter(); Exit(); }
только нужно ещё обосновать, зачем это щастье надо. Потому что внезапно выяснится, что на практике в rwlock надо передавать таймаут и/или CancellationToken и что на самом деле пользователей интересует совсем другое. Например, удобный синтаксис для await lock, устойчивые к thread.Abort() using-и и нормальный синтаксис для actor model, чтобы наконец перестать возиться с наногруппировками и писать легкомасштабируемый код.
Понимаете, вы смотрите на отдельную фичу и она вам так нравится, что вы забываете про все остальные задачи-проблемы, пока нужное не появится в языке. И тогда внезапно оказывается, что нужно было сделать не то, что клиент просил, а предоставить инфраструктуру для решения целого класса проблем, которые прятались за этой недостающей фичей. Вон btn1 выше в одном посте требует "никакого легаси, только вперёд, только хардкор" и следом удивляется "как это без поддержки win7???". Бойтесь желаний, они сбываются
Фаны могут себе позволить такую непоследовательность. Разработчики языка, который пилится не спеша вот уже 15 лет и ещё неизвестно сколько будет пилиться в будущем — нет.
S>>Будет очень много ломающих изменений, да и работе конца-края пока не видно. _>За такую идею я бы сам пару репозиториев поломал, просто из солидарности Тут главное что прогресс виден.
Угу. Главное, чтобы потом парней не захватила ещё более великая идея. Ещё раз им удачи!
Здравствуйте, btn1, Вы писали:
B>Желчь?? В простой констатации факта, что Win8 — это epic fail? Ну извини, я не знаю, какие ещё слова подобрать к [url=www.google.co.za/search?
hl=en&q=Windows+8+провалилась"]полному провалу[/url]. Может, "альтернативный успех"?
интересно, а что доказывает ссылка на поиск в гугле "Windows 8 провалилась?". Рез-ов по этому запросу немного больше чем по запросам "пришельцы похищают людей", но меньше чем по "25 кадр" и намного меньше чем по "чупакабра" и "рак мозга от компьютера"
может лучше на финансовые отчеты посмотреть? или на график стоимости MSFT? (посмотрите, кстати).
S>Ну, могу или там плюсик убрать или тут извиниться. Выбирай
S>Если серьёзно, на практике всё не так, как в теории. Внезапно оказывается, что "хардкод await на Task" ничему не мешает. Точно так же, как хардкод yield return на IEnumerable<>.
Это если кроме "запустил и забыл" ничего не надо, тогда не мешает. А если хочется за задачей и всеми задачами которые она порождает протащить состояние, какую-то информацию для собственного scheduler'a, да даже, например, программер-френдли имя самой задачи и её родительской задачи + время старта каждой для логгирования — приехали.
S>При желании хардкод заменяется на IAsyncStateMachine и IAsyncMethodBuilder, т.е. в будущем никто не запретит добавить в INotifyCompletion S>
S> и извращаться как заблагорассудится. На практике смысла в этом не больше, чем в замене итератора для yield return. Посмотри внутренности дефолтного AsyncMethodBuilder, там весь функционал по большому счёту сводится к m_Task.SetResult.
(ну только TaskLocal), то да, польза от самописных тасков для меня будет сомнительна. Но всегда найдётся человек которому мало решений моих задач, свои решать надо, и уже этот человек придёт на форум и будет ругаться что про него забыли
S>Не, при большом желании можно переписать таск с 0 (где-то пара человекомесяцев минимум), но зачем — мне решительно непонятно. Разве что чтобы возмущаться "опять используют велосипед вместо готового решения"
Да мне бы по-простому — отнаследоваться, и протаскивать буквально пару полей из таска в таск где это надо, и не протаскивать там где не надо. Человеко-дни. Ну может ещё одна-две человеко-ночи, чисто из-за того что с отладкой этого дела сложности могут быть
S>Потому же, почему нельзя вернуть IMyEnumerable<T> из кастомного итератора — во, первых, фичу никто не спроектировал, не закодил, не протестировал и не отправил в продакшн. Во-вторых, идея на корню рубится типовыми сценариями использования. Для IEnumerable это linq, для async — await. Как через них будешь свой чудо-тип протаскивать?
Против IEnumerable почти ничего не имею. А чудо-Task вот надо
_>>А на мониторе свет клином не сошёлся. lock(ReaderWriterLock.Read) и lock(ReaderWriterLock.Write) вполне интуитивно-понятные конструкции. S>Ну ок, можно попросить чтоб в следующей версии добавился S>
S>ILockable { bool TryEnter(); Exit(); }
S>
S>только нужно ещё обосновать, зачем это щастье надо. Потому что внезапно выяснится, что на практике в rwlock надо передавать таймаут и/или CancellationToken и что на самом деле пользователей интересует совсем другое.
ну сразу хотелось бы иметь Task.CurrentTask.CancellationToken (был бы MyTask — легко), да и без него lock(ReaderWriterLock.Read(Timeout)) и т.п., при наличии ILockable вопрос решается тысячей способов. Без него — try/catch/finally и побежали — т.е. никак.
S>Понимаете, вы смотрите на отдельную фичу и она вам так нравится, что вы забываете про все остальные задачи-проблемы, пока нужное не появится в языке. И тогда внезапно оказывается, что нужно было сделать не то, что клиент просил, а предоставить инфраструктуру для решения целого класса проблем, которые прятались за этой недостающей фичей. Вон btn1 выше в одном посте требует "никакого легаси, только вперёд, только хардкор" и следом удивляется "как это без поддержки win7???". Бойтесь желаний, они сбываются
Так и я о чём. Вместо размножения ускоспециализированных фич — дайте инфраструктуру и самую дубовую реализацию построенную на ней (без всяких internal/private для себя, и одного virtual метода для всех). А мы уж дальше сами. Например те же TaskScheduler'ы — вполне себе соответствуют этой парадигме. И вот уже пожалуйста — 20 видов типовых Scheduler'ов искаропки. Не сравнить с ThreadPool три метода на все случаи жизни, и с таймаутами вопрос решён предельно чётко
Здравствуйте, hi_octane, Вы писали:
_>Это если кроме "запустил и забыл" ничего не надо, тогда не мешает. А если хочется за задачей и всеми задачами которые она порождает протащить состояние, какую-то информацию для собственного scheduler'a, да даже, например, программер-френдли имя самой задачи и её родительской задачи + время старта каждой для логгирования — приехали.
Решать такие штуки на уровне тасков — это, имхо, микроменеджмент. Не, никто не запрещает подменять шедулер на каждой задаче (это можно сделать и сейчас, через метод-расширение), но это порождает больше проблем, чем решает. Как насчёт варианта с LogicalCallContext?
_>Ну если мне дадут в Task'х решения задач вроде этих
(ну только TaskLocal), то да, польза от самописных тасков для меня будет сомнительна. Но всегда найдётся человек которому мало решений моих задач, свои решать надо, и уже этот человек придёт на форум и будет ругаться что про него забыли
Ок, принято. Что-то подобное решал, но вспоминать надо Завтра или в понедельник поищу.
_>Да мне бы по-простому — отнаследоваться, и протаскивать буквально пару полей из таска в таск где это надо, и не протаскивать там где не надо. Человеко-дни. Ну может ещё одна-две человеко-ночи, чисто из-за того что с отладкой этого дела сложности могут быть
Если б так просто было между вашими тасками легко может вклиниться чужой код, который про "протащить поля" ни сном, ни духом. Можно кое что нагородить на callcontext, но там есть свои подводные камни.
_>ну сразу хотелось бы иметь Task.CurrentTask.CancellationToken (был бы MyTask — легко), да и без него lock(ReaderWriterLock.Read(Timeout)) и т.п., при наличии ILockable вопрос решается тысячей способов. Без него — try/catch/finally и побежали — т.е. никак.
Угу. За Current.CancellationToken +1024, сам на днях в очередной раз изобретал велосипед.
_>Так и я о чём. Вместо размножения ускоспециализированных фич — дайте инфраструктуру и самую дубовую реализацию построенную на ней (без всяких internal/private для себя, и одного virtual метода для всех). А мы уж дальше сами. Например те же TaskScheduler'ы — вполне себе соответствуют этой парадигме. И вот уже пожалуйста — 20 видов типовых Scheduler'ов искаропки. Не сравнить с ThreadPool три метода на все случаи жизни, и с таймаутами вопрос решён предельно чётко
Засада в том, что сами таски не совсем годятся для инфраструктуры, они заточены под довольно ограниченный набор сценариев. Когда речь доходит до обработки асинхронных последовательностей или до акторов таски в голом виде мало чем помогут.
Ну а пилить инфраструктуру под такие задачи вслепую, без прикладной релизации... не верю, что из этого что-то хорошее выйдет. В общем, надо подкинуть идею про actor based == big thing vNext
S>Сборка очень ранняя, требуется ставить на "чистую" машину без установленной ранее VS (читай — лучше не рисковать и использовать для экспериментов виртуалку).
Еще можно сделать виртуалку в Windows Azure, теперь там в галерее виртуалок есть Visual Studio Professional 14 CTP с уже установленной студией.
Здравствуйте, Sinix, Вы писали:
S>Перечитай предыдущий пост, там смысл по-моему очевиден: MS не получает денег напрямую с новых фич, максимум пользы от них — приманить новых клиентов. Куда важнее не потерять старых.
Если язык не развивается, старые клиенты так же побегут, как сейчас бегут с Жабы.
Сам вопрос по развитию языка не должен стоять как "сколько бабла это принесёт?", потому что это в корне тупо — смешивать коммерцию и науку.
S>Ты в принципе написал то же самое, только ещё раз макнул MS в говно, так как они не делают то, что нравится тебе.
Ну да. Т.е. по-твоему, я один хочу interpolating strings, а счётчик голосовалок я сам накрутил! Глупо рассуждаешь. Не МНЕ нравятся, а МНОГИМ нравятся — я ещё не видел людей, которые бы корчились на облегчение их жизни.
Строки не сделаны и это плохо, потому что сама фича — грошовая и хоть в каком-то виде (тем более для CTP!) могла быть запилена.
S> Надо заметить, конструктива топику это не добавляет
А что ты-то сказал конструктивного, товарищ? Сыпешь техническими доказательствами? Точно так же фонтанируешь идеями как мы все — не надо дартаньянства, ага?
S>Офф: тем не менее, MS очень внимательно стала относиться к поддержке со стороны community.
Не более, чем всегда. От ухода одного Баллмера внутрикорпоративный мир мелкософта не поменялся — он инертен.
S>>>... добавление чего-то нового должно сохранять положительный баланс "затраты/выигрыш" для языка. B>>А как тут измеряется ВЫЙГРЫШ?
S>Офф 2, grammarnazi, не вам лично: выИгрыш Мозайка йз войнов андройда блйн! S>Понятно, что опечатка по Фрейду, но достало уже.
Не умничай, опечатка не хуже "ться" или "парашут" — пруф с количеством результатов. Напоминаю — дартаньяны в другой палате.
S> Проиграть можно очень легко: запороть новой фичей возможность расширения языка
Конкретно по строкам — что они там "запарывают"? Почему на тривиальную проблему надо смотреть как на какое-то вселенское изменение??
Вот были автоинициализаторы переменных и полей: int i = 2; А вот для пропертей этого не сделали! Это УЖЕ концептуальный перекос, хотя 1) фичу для полей всё-таки запилили 2) теперь это делают и для пропертей(!!!) — зачем тогда умничать? К чему все эти рассусоливания на пустом месте, если сами же налажали до этого? НЕПОСЛЕДОВАТЕЛЬНОСТЬ — вот признак лажовенькой команды. Либо все фичи должны "академически" проверяться, доказываться и т.п., либо нечего выпежониваться и запиливать полезняшки по мере более-менее готовому проекту.
B>>Фичи можно как-то сравнить по полезности, но извини, что-то я не припомню никаких революций в мире C#, сильно облегчающих мне жизнь. Зато кучи маленьких, но необходимых вещей так и померли под отговорками тех, кто говнокодил до "эпохи Рослина". S>Тоже писалось выше. Выбор у разработчиков до недавнего времени был не "добавим финтифлюшку/не добавим" а "успеваем выпустить всё, что обязательно должно быть к текущей итерации/не успеваем".
Я про это и написал: революций — не было, но тем не менее, время куда-то профукано — НА ЧТО? Наопмню, для начала — первый "цэшарп" был сделан в 1992 году. Ничего так срок? 12 лет, 220 будней, по 8 часов "работы", а на выходе — мышь. И посмотри на D — язык, который пилят от силы человек пять! Да он уже сейчас по возможностям заткнул C# в нехорошее место. Очевидно, что шарповоды больше тратят время на кофе и квадратики — это ж не мешки ворочать!
B>>Ну вот, скажем, инициализация автопроперти — что, дюже прорывная фича? S>На мой взгляд, на практике полезна разве что для скриптов и прочих поделок.
Это очень частный и прямо скажем — недальновидный, слабопрофессиональный взгляд — простительно, но только для вас лично. Команда же C# эту фичу считает полезной и БУДЕТ делать ввиду очевидной полезности для тысяч прогеров — даже не понимаю, каким боком тут какие-то "скрипты" — вы C# не компилируете что ли?
S> Добавляем валидацию параметров в конструктор (или вы в каждый класс что попало суёте?) и всё удобство моментально идёт лесом.
И как эта валидация пересекается с инициализацией?? Можно пример кода для понятности?
S>Но ок — что надо было перекинуть на другой релиз ради набора подобных мегафич? Генерики? linq? await? dlr?
Покажите ВЕСЬ _внутренний_ набор ToDo команды C# — я расскажу. А жонглировать мегафичами не надо, не ими одними занимались шарпопилы.
S>Ненависть-скандалы-интриги-расследования — эт в flame.comp и в прочие мусорные ветки плиз
Без тебя разберусь, кто интриги, а кто просто жадный буржуй. То, что КОММЕРЧЕСКАЯ фирма жмотит деньги на хороших специалистов — увы, ТОЖЕ необходимая вещь для выяснения правды.
S> Я хочу здесь и сейчас, пусть ценой неудобств, возможность _новый_ код писать на _новом_ языке. Повторюсь: "мэйнстрим" никто никуда не тащит, пусть сидит на FW 2.0 и лелеет свои мегабайты суперкода. S>[/q] S>и, когда они делают ровно то, что просил, возмущаешься S>
S>каким таким немыслимым образом мелкософт решила выпустить VS2014 только под Win8?
S>(если что, проблема скорее всего в win7 без обновлений. У ранних ctp vs2013 те же проблемы были).
У тебя по логике "тройка" что ли? Где связь между ограничением платформы VS и просьбой запилить элементарные строки, которые вообще никакого отношения к Windows не имеют? Сходи на лекции что ли, чем моё время тратить на трололо.
Здравствуйте, btn1, Вы писали:
B>Вот те же замусоленные "инициализаторы автопропертей" (уж извини, пример хороший ) — почему добавление "= expression;" должно вызывать какие-то немыслимые сложности? Чувак, это просто дополнение к синтаксису! Даже семантика не меняется! А значит, твой компилятор должен быть построен так, что расширение "обычного автопроперти" до "инициализируемого" должно достигаться чуть ли не единственной правкой EBNF! Звучит слишком просто, но это так.
То есть ты считаешь, что в существующих инициализаторах полей может быть только expression?
А инициализатор свойства может использовать те же синтаксические узлы, как и инициализатор поля, потому что синтаксически совершенно ничем не отличается?
А когда эти инициализаторы должны выполняться — до тела конструктора или после? до инициализаторов в базовом классе или после? до конструктора базового класса или после?
Нужно ли выполнять инициализатор свойства в базовом классе, если оно virtual и имеет override в производном классе с другим инициализатором?
Компилятор должен быть спроектирован так, чтобы автоматически правильно ответить на все эти вопросы после правки EBNF, правда? И заодно сам сочинить сообщения об ошибках для всех некорректных случаев? Или достаточно сказать "ваша программа не соответствует EBNF"?
Главное чтоб не получился неудобняк как с вторым немерлом
Мозайка йз войнов андройда блйн! 
Ещё, очень советую поработать хоть раз в жизни хотя бы с мааленьким коллективом на 15-20 человек, фантазии про "девять женщин выносят ребёнка за месяц" сразу пропадут. 
Можно пример кода для понятности?
