Здравствуйте, Mazay, Вы писали:
M>... Не верю, что им реально слабо допилить С# по скорости до VisualС++. Они же сами плюсовый компилятор делали, и у них это неплохо получалось (по по крайней мере в VS7 и VS8). Почему нельзя этот опыт перенести на C#? Если верить Шутауту, то C# не сильно от плюсов отстаёт, для UI на персоналках должно хватать.
Где то тут были высказывания разработчиков C# об оптимизациях.
По их словам — не компилятор должен оптимизировать, а JIT, поэтому не делают оптимизации которые могли бы.
Но, ИМХО, уже прошли времена когда софт тормозил из-за того что плохо раскладывается по регистрам или подобной мелочевки. Тормоза больше из-за плохих высокоуровневых решений — программы делают кучу ненужной работы.
Думаю, доля правды есть в таком высказывании: Программы тормозят из-за того что их пишут на С++. Пока они борются с указателями и хедер файлами, допускают более крупные архитектурные просчеты. А манагеры-архитекторы в кучах С++ кода не могут ковыряться.
Почему тормозит новый MSDN при старте? Что-то ненужное там делает. Его случайно не на С++ писали?
Почему тормозит WPF. Виноват скорее всего не .NET, а кривой milcore.dll, который на С++ написан.
Здравствуйте, VladD2, Вы писали:
VD>Вот одна дама пишет о ренесансе С++ в МС. VD>Ваше мнение!...
Ну так... С++ — это худший язык. За исключением всех остальных.
Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом. Использовать Java в MS по понятным причинам невозможно.
Текущее состояние сектора Win32/COM/C++ напоминает ракету, выпущенную когда-то с большой скоростью,
но лишенное поддержки наземной системы наведения. Если написанное в статье — правда, и перекос
стали исправлять, то могу только порадоваться. Это означает появление новых инструментальных средств и
библиотек от Microsoft, а также возвращение C++ на позиции, с которых его незаслуженно списывают.
Здравствуйте, Jack128, Вы писали:
C>>Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом. Использовать Java в MS по понятным причинам невозможно. C>>Так что и остаётся С++ и С. J>А зачем MS нужен кроссплатформенный язык??
Он нужен разработчикам. А разработчики нужны MS.
Если лет 5 всё было просто с доминирующим MS, под который можно было писать и не думать больше ни о чём, то сейчас всё становится интереснее. Есть Mac с неплохой долей рынка, число мобильных устройств с Linux'ом внутри превысит скоро сотню миллионов, производительность снова важна и т.д.
Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики.
Здравствуйте, VladD2, Вы писали:
VD>Всем привет! VD>Вот одна дама пишет о ренесансе С++ в МС. VD>Ваше мнение!...
Мое мнение — эта статья чистый желтяк. "Как говорил один мой знакомый, имеющий представление о том, как думают в Майкрософт...".
В общем не читайте советских газет, и спать будет легче.
Здравствуйте, Геннадий Васильев, Вы писали:
_>>>А что — возьмут да и выкинут нафиг .Net из Windows 8, поигрались и будет, добро пожаловать в реальный мир! CC>>А было бы неплохо.
ГВ>А зачем? Java под Windows работает, так пусть и .Net работает.
Не, пусть работает.
Я немного про другое.
Я про написанные на .NET стандартные утилиты, которыми стало просто тупо неудобно пользоваться из-за того, что они стали пц какие неповоротливые.
Казалось бы надо как-то по-особенному порадоваться, но... Что тут удивительного?! Если MS хочет удвоить бизнес в области инструментальных средств, то надо позаботиться и о native — глупо игнорировать этот сегмент, кто бы что ни говорил. Потом, есть ещё "свежеприобретённая" Nokia со своими мобильниками и кучей C++-ников вокруг — не самая последняя в мире аудитория, так почему бы не смягчить у неё панические настроения, что, мол, придётся переучиваться на .Net?
А ещё тут получается интересная, хотя отчасти и утрированная коллизия. .Net — неплохая штука (в некотором смысле), но программы под него, худо-бедно, но стали переносимыми и разные mono-вцы носом роют землю, чтобы эта переносимость таки имелась. То есть потенциально .Net-разработка может свалить куда-нибудь на *nix, тогда как приложение, привязанное к WinAPI ты уже так просто на *nix не перенесёшь, способствуя тем самым распространению самой Windows. Но тут странность — MS сейчас как-то не слишком вкладывается в поддержку C++, так или иначе подталкивая C++-ников к переходу на переносимую платформу, а на фига оно MS-у, такое счастье? Можно понять, почему IBM с её зоопарком аппаратуры вкладывается в переносимую Java, но у Microsoft-то не такие условия — ей же не нужно скрещивать iSeries, zSeries, eSeries, что-там-ещё-Series. Так зачем платить больше? (c)
Короче, можно, наверное, назвать эти события "ренессансом C++ в MS", но как по мне, это лишь исправление давно сложившегося перекоса. Что там будет дальше с managed-платформой — посмотрим. Хейлсберг — мастак сотворять вещи, сильно не похожие на Microsoft tools.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
C>Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом. Использовать Java в MS по понятным причинам невозможно.
C>Так что и остаётся С++ и С.
Здравствуйте, lazy_walrus, Вы писали:
_>А что — возьмут да и выкинут нафиг .Net из Windows 8, поигрались и будет, добро пожаловать в реальный мир!
А было бы неплохо.
Здравствуйте, Jack128, Вы писали:
J>а можно по пунктом, какие просчёты, которые нельзя исправить, имеются в дот нете??
Чуть менее чем все решения дизайнеров .НЕТ.
Например хардкод опкодов типа add, sub итп в систему команд .НЕТ привел к тому что создание аналога std::valarray из C++/STL невозможно.
Очень слабая система типов. Например нельзя сделать безопасный доступ без рантайм проверки к элементам массива даже если я могу доказать что индекс никогда не выйдет за приделы массива.
Отсутствие неизменяемых типов данных.
Отсутствие безопасных http://en.wikipedia.org/wiki/Tagged_union
Отсутствие структурных типов, что приводит к невозможности создания нормальных кортежей.
Совершенно дебильные соглашения о вызовах и отсутствие хвостовой рекурсии. То что есть работает так что лучше бы не было.
...
Короче мне лень перечислять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
CC>Я про написанные на .NET стандартные утилиты, которыми стало просто тупо неудобно пользоваться из-за того, что они стали пц какие неповоротливые.
У меня на компьютере FireFox, в котором по умолчанию открыты более десятка вкладок, открывается быстрее, чем PowerShell.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Здравствуйте, Mazay, Вы писали:
M>Не верю, что им реально слабо допилить С# по скорости до VisualС++.
Бесполезно.
.НЕТ быстрым быть не может.
И не по тому, что менеджед, а по тому что криво менеджед.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ваше мнение!...
Лучше бы D проталкивали, или, если политика партии не позволяет, то свой клон. А так, почему бы и нет — всё равно от С++ в ближайшее время никуда не денешься, может рефакторинги какие-то к студии прикрутят, или ещё что-то полезное сделают.
Здравствуйте, Cyberax, Вы писали:
VD>>Вот одна дама пишет о ренесансе С++ в МС. VD>>Ваше мнение!... C>Ну так... С++ — это худший язык. За исключением всех остальных. C>Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом.
А что MS пыталась сделать его кроссплатформенным?
Вообще если почитать ссылку, которую дал Влад, там совсем не о кроссплатформенности речь. А скорее наоборот.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Mazay, Вы писали:
M>>Не верю, что им реально слабо допилить С# по скорости до VisualС++. WH>Бесполезно. WH>.НЕТ быстрым быть не может. WH>И не по тому, что менеджед, а по тому что криво менеджед.
а можно по пунктом, какие просчёты, которые нельзя исправить, имеются в дот нете??
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Jack128, Вы писали:
J>>а можно по пунктом, какие просчёты, которые нельзя исправить, имеются в дот нете?? WH>Чуть менее чем все решения дизайнеров .НЕТ. WH>Например хардкод опкодов типа add, sub итп в систему команд .НЕТ привел к тому что создание аналога std::valarray из C++/STL невозможно.
не знаком с плюсами, не могу прокомментировать. WH>Очень слабая система типов. Например нельзя сделать безопасный доступ без рантайм проверки к элементам массива даже если я могу доказать что индекс никогда не выйдет за приделы массива.
есть принципиальные проблемы расширить ран тайм нужным образом? WH>Отсутствие неизменяемых типов данных.
есть принципиальные проблемы добавить оные? WH>Отсутствие безопасных http://en.wikipedia.org/wiki/Tagged_union
вроде тоже самые Алг. типы данных, чем плоха эмуляция на классах? WH>Отсутствие структурных типов, что приводит к невозможности создания нормальных кортежей.
а чем Nemerle'вские/F# овские кортежы плохи?? WH>Совершенно дебильные соглашения о вызовах и отсутствие хвостовой рекурсии. То что есть работает так что лучше бы не было.
ну дык в чем проблема научить оптимизировать то?? у ран тайма вся инфа для этого есть? WH>... WH>Короче мне лень перечислять.
то что ты перечислил — это ж не принципиальные проблемы, все это можно добавить без поломки существующего кода. Другое дело, что MS особо не чешется с разгоном ран тайма, ну так для большенства приложений все более менее нормально работает, вот они и забили..
Здравствуйте, Sinix, Вы писали:
S>1. Как это должно было быть реализовано? Я с наскока могу предложить только крайне извращённый способ — JIT заменяет op_Addition и co для встроенных типов, для всех остальных — просто вызов методов. Очевидно, вы имели в виду более юзабельный вариант.
Именно так.
И это самый прямой метод.
Почему ты называешь его извращенным не ясно.
Ибо JIT ну совершенно без разницы что знать в лицо опкод add или метод op_Addition
S>2.А нафига иметь даже потенциальную фозможность переизобрести строку, массив etc? Точнее — пущщай оно будет, но зачем затачивать рантайм под такие крайне редкие юз-кейзы?
Это нужно для того чтобы можно было писать обобщенный код.
Попробуй, создай аналог std::valarray на генериках .НЕТ.
S>unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде.
Это только тебе кажется что unsafe.
А когда я говорю доказать я имею в виду доказать.
Иди читай про type refinements
И только не говори что это ни кому не нужно.
У меня полно кода, где это не только нужно, но и очень легко доказывается.
S>FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом. Ой лол.
Не путай кривущий рантайм .НЕТ и рантайм вообще.
S>Есть тюплы, не хватает только синтаксического сахара для них.
А теперь попробуй передать анонимный тип с именованными полями из одной сборки в другую.
S>Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента.
А это еще одна проблема не дающая нормально работать.
Имея неизменяемые структуры рантайм сам может решать делать и value или ref в зависимости от их реального размера.
S>Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф.
Ты вообще читаешь, что я пишу?
Ты знаешь с какой скоростью начинает работать код?
А я знаю. Измерял и плакал.
Хотя хвостовой вызов должен быть как минимум не медленней обычного.
А знаешь по чему? А по тому что CAS.
А CAS появился из-за того что мелкософт не осилил CBS.
S>Что характерно, все претензии никак не соотносятся с исходным утверждением — ".НЕТ быстрым быть не может."
Что характерно все претензии к моим претензиям исходят из недостатка образования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinix, Вы писали:
S>Пардон, я просто не успеваю за мыслью: начали с очень узкой фичи, и внезапно перешли к статической верификации кода. Лично я всеми конечностями за. Увы, мейнстрим-реализация от МС — code contracts — оччень малопрактична, но у них в загашнике есть Verve OS (по ссылке — pdf).
С вероятностью 99.9999% там оно и останется.
Не слушает мелкософт свой ресерч.
WH>>В .НЕТ да. А по жизни нет. S>Ну так мы обсуждаем решения в .net И да, мне самому не нравится как в шарпе реализованы анонимные типы.
Ну да. Я говорю .НЕТ жутко крив.
Ты вроде начал спорить но теперь со всем соглашаешься
S>Сборок. У нас есть ABI аля SomeMethod(SomeVal val). После очередной правки SomeVal внезапно становится ref-типом — или перекомпилируем весь код, или ловим исключения в рантайме. Это можно обойти, но придётся явно вводить classorstruct-типы, т.е. одними изменениями в компиляторе не обойтись.
Так я сразу говорил рантайм .НЕТ крив.
S>Заодно нашлась заметка про оптимизации tailcall в .NET 4/
Всеравно тормозит.
Хвостовой вызов должен быть в самом худшем случае таким же по стоимости как простой вызов.
Но обычно он должен быть дешевле.
Ибо это обычный goto.
А если еще и аргументы передавать через регистры, а не через стек то там производительность как у обычных циклов должна быть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали: I>Здравствуйте, Silver_S, Вы писали: S_S>>Почему тормозит WPF. Виноват скорее всего не .NET, а кривой milcore.dll, который на С++ написан.
I>А ты загляни во внутрь, там столько оверхеда, что некуда деваться.
В самом WPF или у milcore тоже доступны исходники?
В WPF конечно тоже оверхеда должно быть достаточно. Если они там так активно с Dispatcher взаимодействуют, чуть ли не на каждом вызове метода у Dispatcher спрашивают из правильного потока вызов. И с Freezable тоже...
Но тормоза кажется именно из-за самой milcore. Неправильно они все сделали.
Надо было так: первый слой это просто окно в котором лежит D3D девайс, вместе с D2D, готовые к работе и с заплатанными косяками. Хотябы только заплатки на косяки описанные в MSDN. И плюс Application (очередь сообщений и подобное).
Как ни странно, даже это сделать не так просто сделать. Sample набрость минутное дело, но сложнее если надо без косяков и кривостей при Resize, переключнии режимов полноэкранный/оконный, ....
Для первого слоя все, больше ничего не надо, никаких медиа интегрейшен.
Поверх него уже писать WPF, а кому надо, будет напрямую использовать в обход WPF.
Никкаких API на C++, COM тут не надо, полноценный managed API — ну нету у D3D функций которые надо быстро и часто вызывать, все данные в байтовых массивах подаются. Даже у D2D вызывать всякие DrawLine, почти без оверхеда — все очень быстро работает.
С++, COM программеров нельзя и близко подпускать к дизайну такого API. Они там наделают.
Вот как можно назвать такой паттерн, используемый в DX10 API ?: взять несколько разных объектов, с разным набором функций(методов). Соединить в один интерфейс, тип объекта указывать при создании. А методы этих объектов свалить в кучу, если вызовется несоответствующий метод выбрасывать Exception. Ну сэкономили они несколько записей об интерфейсах в реестре. Может тогда COM тут не нужен? У программера привыкшего к .NET рука бы не повернулась такого сделать.
WPF надо было начинать с полноценного Managed DX (а не оберткой вокруг кривого COM API).
Или если надо сразу два варианта. Только потом всякие XNA для XBox. Раз у всех Винда от MS, MS и должны этим заниматься.
Здравствуйте, Cyberax, Вы писали:
C>Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом. Использовать Java в MS по понятным причинам невозможно.
Здравствуйте, Jack128, Вы писали:
C>>Сделать C# реально кроссплатформенным не получилось, так что его популярность ограничена Windows'ом. Использовать Java в MS по понятным причинам невозможно.
C>>Так что и остаётся С++ и С.
J>А зачем MS нужен кроссплатформенный язык??
Вот-вот. Ситуация реально странная. Пока что все аргументы от МС в пользу С++ сводятся к производительности и открытию доступа к каким-то мифическим возможностям то ли операционки, то ли компьютера (new possibilities that the Windows platforms unlocks for applications). На мой нюх это какая-то гнилая отмазка. Не верю, что им реально слабо допилить С# по скорости до VisualС++. Они же сами плюсовый компилятор делали, и у них это неплохо получалось (по по крайней мере в VS7 и VS8). Почему нельзя этот опыт перенести на C#? Если верить Шутауту, то C# не сильно от плюсов отстаёт, для UI на персоналках должно хватать.
Здравствуйте, VladD2, Вы писали:
VD>Всем привет!
VD>Вот одна дама пишет о ренесансе С++ в МС.
VD>Ваше мнение!...
Это же ужас. Итак было видно что с visual studio гайки закручивают так теперь совсем будут дожимать чтобы деньгу до $2bn догнать. а про кому и вин8 это все желтизна некомпетентная.
Здравствуйте, WolfHound, Вы писали:
WH>.НЕТ быстрым быть не может.
Ха-ха-ха. Понеслась.. душа в рай. Ой помнится как сначала все от COM-а кипятком писали. А потом те же самые, кто нахваливал COM стали кричать какое это г...
Новый виток спирали
Здравствуйте, CreatorCray, Вы писали:
_>>А что — возьмут да и выкинут нафиг .Net из Windows 8, поигрались и будет, добро пожаловать в реальный мир! CC>А было бы неплохо.
А зачем? Java под Windows работает, так пусть и .Net работает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Cyberax, Вы писали:
J>>А зачем MS нужен кроссплатформенный язык?? C>Он нужен разработчикам. А разработчики нужны MS.
не нужны MSу абстрактные разработчики, им нужны разработчики под платформы от MS.
C>Если лет 5 всё было просто с доминирующим MS, под который можно было писать и не думать больше ни о чём, то сейчас всё становится интереснее. Есть Mac с неплохой долей рынка, число мобильных устройств с Linux'ом внутри превысит скоро сотню миллионов, производительность снова важна и т.д.
C>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики.
да не нужны мелкософту кроссплатформенные приложения.
Здравствуйте, Jack128, Вы писали:
C>>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики. J>да не нужны мелкософту кроссплатформенные приложения.
Ну, Офис под Мак то они развивают. Там даже Риббон есть
Здравствуйте, Jack128, Вы писали:
C>>Он нужен разработчикам. А разработчики нужны MS. J>не нужны MSу абстрактные разработчики, им нужны разработчики под платформы от MS.
Они уже не полный монополист, чтобы всем диктовать условия. Особенно на мобильных платформах.
C>>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики. J>да не нужны мелкософту кроссплатформенные приложения.
Они нужны разработчикам.
Здравствуйте, Sorc17, Вы писали:
S>Здравствуйте, CreatorCray, Вы писали:
CC>>Я про написанные на .NET стандартные утилиты, которыми стало просто тупо неудобно пользоваться из-за того, что они стали пц какие неповоротливые.
S>У меня на компьютере FireFox, в котором по умолчанию открыты более десятка вкладок, открывается быстрее, чем PowerShell.
powershell — это конечно еще тот тормоз, но что то мне кажется тут дело не в нете, а кривых руках разрабов PS. туча дотнетовских приложений нормально стартуют..
Здравствуйте, Jack128, Вы писали:
S>>У меня на компьютере FireFox, в котором по умолчанию открыты более десятка вкладок, открывается быстрее, чем PowerShell. J>powershell — это конечно еще тот тормоз, но что то мне кажется тут дело не в нете, а кривых руках разрабов PS. туча дотнетовских приложений нормально стартуют..
Речь скорее всего о первом старте, когда рантайм подгружается в первый раз. Оно действительно медленно.
Здравствуйте, Jack128, Вы писали:
J>то что ты перечислил — это ж не принципиальные проблемы, все это можно добавить без поломки существующего кода. Другое дело, что MS особо не чешется с разгоном ран тайма, ну так для большенства приложений все более менее нормально работает, вот они и забили.. Ага, конечно.
Только всю стандартную библиотеку переписать с потерей совместимости... а так да... никаких проблем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Jack128, Вы писали:
WH>>Очень слабая система типов. Например нельзя сделать безопасный доступ без рантайм проверки к элементам массива даже если я могу доказать что индекс никогда не выйдет за приделы массива. J>есть принципиальные проблемы расширить ран тайм нужным образом?
Как ты представляешь себе расширение существующего рантайма?
WH>>Отсутствие неизменяемых типов данных. J>есть принципиальные проблемы добавить оные?
Чуть менее чем весь FCL придется выбросить нафиг.
WH>>Отсутствие безопасных http://en.wikipedia.org/wiki/Tagged_union J>вроде тоже самые Алг. типы данных, чем плоха эмуляция на классах?
Тем что они — ссылочные, а ссылочные объекты всегда в куче создаются, что ведет к серьезному оверхеду при определенных сценариях использования.
WH>>Отсутствие структурных типов, что приводит к невозможности создания нормальных кортежей. J>а чем Nemerle'вские/F# овские кортежы плохи??
Тем что они эмулированы конечным множеством обобщенных типов. Ну и как видишь их сейчас минимум два семейства: System.Tuple, Nemerle.Builtins.Tuple. В других функциональных языках, изобретенных до .NET 4.0 возможно тоже что-то свое.
WH>>Совершенно дебильные соглашения о вызовах и отсутствие хвостовой рекурсии. То что есть работает так что лучше бы не было. J>ну дык в чем проблема научить оптимизировать то?? у ран тайма вся инфа для этого есть?
Здравствуйте, WolfHound, Вы писали:
WH>.НЕТ быстрым быть не может. WH>И не по тому, что менеджед, а по тому что криво менеджед.
Да ладно! Ошибки есть, но их не так уж и много. С точки зрения скорости больше проблем вызывает GC, а не какие-то там проблемы рантайма. Единственный серьезный косяк это пожалуй — ковариантность для массивов. Это действительно лютые тормоза без какой либо необходимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, MasterZiv, Вы писали:
>> Если MS хочет удвоить бизнес в области инструментальных средств, то надо >> позаботиться и о native
MZ>Они бы раньше заботились, блин, когда Fortran продавали.
There are no left time to do right things. (с) А сейчас, видимо, wrong things припёрли, вот и time нашлось.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, CreatorCray, Вы писали:
ГВ>>А зачем? Java под Windows работает, так пусть и .Net работает. CC>Не, пусть работает. CC>Я немного про другое. CC>Я про написанные на .NET стандартные утилиты, которыми стало просто тупо неудобно пользоваться из-за того, что они стали пц какие неповоротливые.
Так это вопросы к тем, кто втыкает .Net куда надо и куда не надо. Сам-то .Net здесь так, рядом оказался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Так это вопросы к тем, кто втыкает .Net куда надо и куда не надо. Сам-то .Net здесь так, рядом оказался.
Ну, вот если убрать FW из поставки, то ни один стандартный компонент, входящий в поставку нельзя будет написать на .NET.
Кому надо будет — поставит FW отдельно.
Здравствуйте, Cyberax, Вы писали:
CC>Если лет 5 всё было просто с доминирующим MS, под который можно было писать и не думать больше ни о чём, то сейчас всё становится интереснее. Есть Mac с неплохой долей рынка
CC>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики.
Кому лень ходить по ссылке(статья вообще большая и о другом): ребята написали игруху, выложили её в app store, success story и всё такое. В общем, ничего сильно интересного, кроме маленького абзаца:
О том, что привело к успеху в разработке игры:
•C# + Visual Studio + Resharper + Unity3d – с программисткой точки зрения.
Коментарии излишни, бо это не столь нелюбимое нелюбителями MS get the facts, а самая что ни на есть жизненная жизнь.
О том, что привело к успеху в разработке игры:
YKU> •C# + Visual Studio + Resharper + Unity3d – с программисткой точки зрения.
YKU>Коментарии излишни, бо это не столь нелюбимое нелюбителями MS get the facts, а самая что ни на есть жизненная жизнь.
YKU>Вобщем, не всё так однозначно.
Угу, цитата из википедии, подтверждаемая содержанием сайта Unity3d:
— пока не поддерживает Linux, хотя разработки ведутся
— не поддерживает Windows Mobile и Windows Phone 7
Жизненная кроссплатформенность, да...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я бы сказал даже — жизненная кросплатформенность средств, построенных на платформе, изначально разработанной и продвигаемой самой Microsoft.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Например хардкод опкодов типа add, sub итп в систему команд .НЕТ привел к тому что создание аналога std::valarray из C++/STL невозможно.
Два вопроса:
1. Как это должно было быть реализовано? Я с наскока могу предложить только крайне извращённый способ — JIT заменяет op_Addition и co для встроенных типов, для всех остальных — просто вызов методов. Очевидно, вы имели в виду более юзабельный вариант.
2.А нафига иметь даже потенциальную фозможность переизобрести строку, массив etc? Точнее — пущщай оно будет, но зачем затачивать рантайм под такие крайне редкие юз-кейзы?
WH>Очень слабая система типов. Например нельзя сделать безопасный доступ без рантайм проверки к элементам массива даже если я могу доказать что индекс никогда не выйдет за приделы массива.
unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде.
Как вариант, можно предусмотреть синтаксический сахар, но внутри всё равно будет небезопасная операция.
WH>Отсутствие неизменяемых типов данных.
Если требуется — реализуется за пару часов проверкой при компиляции. Ради спортивного интереса делал рабочий прототип правила для FxCop пару лет назад. На практике оказался малополезен, т.к. большинство типов-значений можно упихнуть в структуры, а они по соглашению immutable.
WH>Отсутствие безопасных http://en.wikipedia.org/wiki/Tagged_union
FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом.
WH>Отсутствие структурных типов, что приводит к невозможности создания нормальных кортежей.
Есть тюплы, не хватает только синтаксического сахара для них. Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента.
WH>Совершенно дебильные соглашения о вызовах и отсутствие хвостовой рекурсии. То что есть работает так что лучше бы не было.
Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф.
Что характерно, все претензии никак не соотносятся с исходным утверждением — ".НЕТ быстрым быть не может."
Здравствуйте, yoriсk.kiev.ua, Вы писали:
CC>>Т.е. если я сейчас хочу писать кроссплатформенное приложение, то у меня особого выбора и нет, всё больше получается C++ для ядра и местный фреймворк для графики. YKU>А мужики-то не знают. Вот эти к примеру: http://habrahabr.ru/blogs/gdev/117564/
Что смотреть? Примитивный платформер, его хоть на HTML5 скоро можно писать будет.
Здравствуйте, WolfHound, Вы писали:
WH>Именно так. WH>Почему ты называешь его извращенным не ясно.
Ок, понял что имелось в виду. Раз уж мы хотим вызывать в генериках операторы op_***() (а иначе никак), то разумно использовать тот же синтаксис и для встроенных типов. В принципе, можно не ломать совместимость и добавить костыль для arithmetic-генериков — всё равно для каждого value-типа jit генерит свой код. Но криво, да
S>>unsafe. Потому что с точки зрения рантайма вы занимаетесь колдунством и следовательно, он не может верифицировать IL. Без верификации мы легко получим кучу дыр в как бы безопасном коде. WH>Это только тебе кажется что unsafe. WH>У меня полно кода, где это не только нужно, но и очень легко доказывается.
Я пока не убеждён, что это настолько общий случай, что окупит переработку рантайма, но спорить не буду.
S>>FieldOffsetAttribute. Потому что в 90% случаев рантайм не сможет гарантировать валидность подобных структур. Для редких частных случаев вполне можно организовать проверку самописным правилом. WH>Не путай кривущий рантайм .НЕТ и рантайм вообще.
Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий?
S>>Есть тюплы, не хватает только синтаксического сахара для них. WH>А теперь попробуй передать анонимный тип с именованными полями из одной сборки в другую.
Анонимный тип и tuple — это разные вещи, не?
S>>Почему тюплы — не struct разжёвывалось неоднократно, если коротко — структура с 3 и > полями будет дороже при передаче в качестве аргумента. WH>А это еще одна проблема не дающая нормально работать. WH>Имея неизменяемые структуры рантайм сам может решать делать и value или ref в зависимости от их реального размера.
Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью и object.ReferenceEquals, которые внезапно поломаются при расширении структуры.
S>>Ну вот зачем так подставляться? tail.-префикс присутствует со 2го рантайма. Если не устраивает — могу поискать нормальный пруф. WH>Ты вообще читаешь, что я пишу?
Да, читаю.
WH> отсутствие хвостовой рекурсии
И как я должен догадаться, что отсутствие == тормоза?
WH>Ты знаешь с какой скоростью начинает работать код?
Нет — хвостовая рекурсия мне ни разу не потребовалась.
WH>А знаешь по чему? А по тому что CAS.
А можно пруф?
WH>Что характерно все претензии к моим претензиям исходят из недостатка образования.
Вам посраться или пообщаться? Если первое — беру самоотвод, если второе — поумерим тон?
Здравствуйте, Sinix, Вы писали:
S>Я пока не убеждён, что это настолько общий случай, что окупит переработку рантайма, но спорить не буду.
Ну ты статьи то почитай.
Это на самом деле чуть меньше чем 100% кода.
Причем доказательства не только скорость дают, но и делают не нужными юнит тесты.
S>Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий?
Чуть меньше чем все функциональные языки, которые компилируются в нативный код.
S>Анонимный тип и tuple — это разные вещи, не?
В .НЕТ да. А по жизни нет.
Я же говорю .НЕТ кривой.
S>Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью
С бинарной совместимостью чего?
Код компилируется внутри домена.
Так что никаких проблем.
S>и object.ReferenceEquals, которые внезапно поломаются при расширении структуры.
Почему внезапно? Если хочешь object.ReferenceEquals то скажи что тип Reference.
Если не сказал, то не будет ни какого object.ReferenceEquals.
А учитывая, что ReferenceEquals нужен очень редко...
WH>>Ты знаешь с какой скоростью начинает работать код? S>Нет — хвостовая рекурсия мне ни разу не потребовалась.
А мне требовалась.
WH>>А знаешь по чему? А по тому что CAS. S>А можно пруф?
Давно читал где-то.
Да и с чего оно так тормозить то может если не из-за этого?
Ибо если это не объяснение причин, то тогда можно смело заявить что мелкософта полные ламеры. Ибо это тривиальная оптимизация, которую сделать не правильно просто не реально.
WH>>Что характерно все претензии к моим претензиям исходят из недостатка образования. S>Вам посраться или пообщаться? Если первое — беру самоотвод, если второе — поумерим тон?
А кто первым начал?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Причем доказательства не только скорость дают, но и делают не нужными юнит тесты.
Пардон, я просто не успеваю за мыслью: начали с очень узкой фичи, и внезапно перешли к статической верификации кода. Лично я всеми конечностями за. Увы, мейнстрим-реализация от МС — code contracts — оччень малопрактична, но у них в загашнике есть Verve OS (по ссылке — pdf).
S>>Ок, какой рантайм может предложить достаточно общее решение без неприятных последствий? WH>Чуть меньше чем все функциональные языки, которые компилируются в нативный код.
Так, я по-прежнему торможу — почему-то не узнал в лицо атд и тут целиком и полностью неправ
S>>Анонимный тип и tuple — это разные вещи, не? WH>В .НЕТ да. А по жизни нет.
Ну так мы обсуждаем решения в .net И да, мне самому не нравится как в шарпе реализованы анонимные типы.
S>>Это породит кучу неприятных сюрпризов, начиная с граблей с бинарной совместимостью WH>С бинарной совместимостью чего?
Сборок. У нас есть ABI аля SomeMethod(SomeVal val). После очередной правки SomeVal внезапно становится ref-типом — или перекомпилируем весь код, или ловим исключения в рантайме. Это можно обойти, но придётся явно вводить classorstruct-типы, т.е. одними изменениями в компиляторе не обойтись.
WH>>>А знаешь по чему? А по тому что CAS. WH>Да и с чего оно так тормозить то может если не из-за этого?
Действительно нашёл пруф и там ссылаются на ту же статью, что я приводил в первом посте.
Заодно нашлась заметка про оптимизации tailcall в .NET 4/
WH>А кто первым начал?
Я? Тогда пардон и спасибо!
Здравствуйте, Silver_S, Вы писали:
S_S>WPF надо было начинать с полноценного Managed DX (а не оберткой вокруг кривого COM API).
Соглашусь. Стоило начать с более навороченной, векторной ГУИ либы, на замену GDI+. А так, мы имеем две технологии для создания GUI на .Net, которые трудно совмещать, но у каждой есть различные, зачастую непересекающиеся с другой, достоинства. На GDI быстрее рисовать, но трудно компоновать. На WPF гораздо удобнее компоновать, но хардкорный рендеринг медлителен.
Здравствуйте, FR, Вы писали:
VD>>Ваше мнение!...
FR>Наверно не последнюю роль в этом ренессансе сыграло то что будущая Win 8 должна работать на маломощных устройствах с ARM процессорами.
Да вообще ARM в т.ч. на мобайл-платформах сильно подгадили менеджед-разработке.
