Достоинства и недостатки языка C#

[Anton_Peplov]

Тема навеяна этим сообщением:

Pphantom в сообщении #1191356 писал(а):

P.S. Кстати, использовать для вычислительного моделирования C# Вам кто-то подсказал? Или сами догадались... Просто я еще понимаю, когда это делается потому, что этот язык уже известен, а что-то другое учить лень/некогда/поздно. Но начинать с нуля... В общем, Вы какой-то уникальный образец человека, который умудряется делать все возможные ошибки (а иногда - и невозможные).

В общем, я именно тот человек, который начал программировать сразу на C# (ну, ученические упражнения на Паскале не считаем) и за много лет с ним сроднился. Однако же интересно послушать мнения людей, знающих несколько языков и потому могущих сравнивать. Итак, чем мой родной C# хорош и чем он плох? В частности, чем он плох для вычислительного моделирования?

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

[aa_dav]

Ну если сравнивать с С++, то меньший контроль за памятью и отсутствие возможности ручной оптимизации а-ля SSE и т.п.
Но для вас вряд ли это будет критичным делом, потому что на таких вещах можно ну раз в 10 в критичных узлах повысить скорость, но для этого в C# надо совсем не знать про cache-friendly и наворотить совсем уж безобразное что-то.
Если не собираетесь за деньги продавать продукт, то можно о таких вещах не страдать.

P.S.

Хотя еще немаловажным может быть вопрос наличия готовых программных библиотек тематических. Тут опять таки всё очевидно.

[rockclimber]

Anton_Peplov в сообщении #1191416 писал(а):

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

У меня нет опыта выжимания всех соков из процессора и памяти ни на одном языке (я обычно обходился оптимизациями самого алгоритма, мне хватало), но есть опыт чтения тех самых форумов программистов Обычно главная претензия к подобным языкам заключается в том, что они выполняются в виртуальной машине, которая "тормозит". Главный ответ на эту претензию обычно заключается в том, что виртуальные машины уже давно научились генерировать нативный код и код этот по скорости не уступает С/С++. Еще, как я понимаю, может подтормаживать Garbage Collector, но эта проблема возникает только если создавать и уничтожать объекты миллионами.
А дальше надо уже лезть в дебри самого языка...

[mustitz]

Для меня он плох тем, что слабо интегрируется с Linux. Можно использовать Mono, но... я не рискнул пробовать. Даже в случае простейшего кинуть что-то в стандартный syslog непонятно где искать ответ.

[kwakush]

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

[Munin]

Очень долго "дети C++" (такие как Java и C#) существенно отставали от него в том плане, что заимствовали OOP, но не заимствовали templates. Соответственно, на templates гораздо лучше делается стандартная библиотека, особенно контейнеры.

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

[warlock66613]

rockclimber в сообщении #1191422 писал(а):

Главный ответ на эту претензию обычно заключается в том, что виртуальные машины уже давно научились генерировать нативный код и код этот по скорости не уступает С/С++.

Не совсем так даже. Тут две разных претензии: "ненативный" код и сборщик мусора.

Что касается ненативности кода, то в случае C# если собрать основную часть программы в виде дллки под современную версию .NET и дллку эту загачить, то виндовый NGen сервис там же её сразу и заджитит - скомпилирует в нативный код то бишь (более-менее вменяемые разработчики это знают). Правда, дженерики джитятся только в рантайме, но в основном это тормоза на старте приложения, а не во время выполнения.

Что касается сборщика мусора, то он как раз ускоряет работу программы... кроме периодических моментов собственно сборки мусора - и есть области где эта непредсказуемость (а не тормоза как таковые) критична, но их немного.

Munin в сообщении #1191447 писал(а):

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

Не знаю как в Java, а в C# дженерики прямо-таки кардинально повлияли и на стандартную бибилиотеку (в частности дженерики породили linq со всеми последствиями) и вообще на всю экосистему. Именно благодаря дженерикам начался массовый переход с ООП на (как я его называю) квазифункциональное программирование. Современный код на C# гораздо больше похож на F#, чем на первородную Java, и всё благодаря дженерикам. Замечу, кстати, что в отличие от Java, где дженерики являются синтаксическим сахаром, в C# информация о типах сохраняется и в рантайме и существенно увеличивает производительность благодаря элиминации боксинга/анбоксинга.

[mustitz]

ООП вообще не очень дружит с эффективностью вычислений. С точки зрения производительности однородные данные лучше помещать вместе. Так что если у нас есть массив объектов/структур, то с точки зрения производительности лучше иметь отдельные массивы для каждого поля. Тогда то же вычисление суммы по определенному полю будет эффективнее использовать кеш процессора. Плюс есть возможность заюзать SIMD-ы.

[Pphantom]

Раз уж мое сообщение послужило затравкой, наверное, стоит пояснить, что я сам имел в виду. Чем C# хорош или плох "вообще", наверное, обсуждать бессмысленно - для разных задач нужны разные языки, одни и те же свойства могут быть и хорошими, и плохими в разных условиях. А вот конкретно для вычислительного программирования список недостатков C#, на мой взгляд, выглядит так:

1) Одновременное отсутствие и низкоуровневых возможностей (в отличие от C), и целевой оптимизации языка под соответствующие задачи (в отличие от Fortran). Как следствие, весьма умеренное быстродействие.
2) Неудачный (с учетом п.1) синтаксис, унаследованный от C. То, что можно, нужно и полезно в "замене ассемблера", в ЯВУ в основном является источником дополнительных проблем. Это приводит к многочисленным мелким ошибкам, тем более неудобным, что вычислительные программисты, как правило, в первую очередь являются специалистами в какой-то другой области.
3) Общее развитие языка "не в ту сторону". В нем много возможностей, de facto не используемых в вычислительном программировании, необходимость поддержки которых так или иначе усложняет развитие того, что требуется. Как следствие, у "конкурентов" зачастую просто лучше с поддержкой чего-нибудь полезного.
4) Распространение языка только на одной платформе, во многих других отношениях малопригодной для вычислительных задач. Да, есть Mono, но это виртуозно закрученный костыль, использование которого оправдано только при сильнейшей необходимости переноса уже имеющегося кода, но не для создания нового. На кластерных архитектурах реализаций C#, как правило, просто нет.
5) Проблемы с совместимостью разных версий и, скажем так, общая репутация MS как места, где на проблемы такого рода не принято обращать внимание. Соответственно, как минимум отсутствие гарантии того, что время жизни кода сможет превысить 5-6 лет.
6) Фактическое отсутствие готового и доступного кода, реализующего те или иные методы (в смысле вычислительной математики), а также сложности использования старого кода, написанного на других языках.
7) Ориентация стандартных библиотек языка на методологию работы, неудобную в исследовательских вычислительных задачах.

[mustitz]

warlock66613 в сообщении #1191452 писал(а):

Что касается сборщика мусора, то он как раз ускоряет работу программы... кроме периодических моментов собственно сборки мусора - и есть области где эта непредсказуемость (а не тормоза как таковые) критична, но их немного.

Не знаю, не уверен. Нет, я допускаю, что возможен сценарий, когда GC ускорит работу. Но... увеличение используемой памяти негативно влияет на работу кешей процессора. Особенно, когда часть используется, часть неизвользуется. TLB тоже больше засоряется. Опять же, если у нас объекты выделяются в стеке и там же уничтожаются, то такое выделение не приводит к локам и работает со скоростью инструкции сложения. Сомневаюсь, что GC сможет понять такой паттерн из обычного использования.

[warlock66613]

mustitz в сообщении #1191457 писал(а):

Опять же, если у нас объекты выделяются в стеке и там же уничтожаются, то такое выделение не приводит к локам и работает со скоростью инструкции сложения. Сомневаюсь, что GC сможет понять такой паттерн из обычного использования.

Нет, конечно, не сможет. Но подавляющая часть программ использует динамическое выделение/освобождение памяти (то есть в куче, а не на стеке). И оно с GC несопоставимо быстрее, хоят и не сводится к инструкции сложения.

[aa_dav]

Munin в сообщении #1191447 писал(а):

Но по слухам, в более свежих версиях "детки" обзавелись шаблончиками.

Дженерики это всё таки не шаблоны. Я плотно не работал, но из того что знаю действительно более продвинутая версия у C# (чем у Java).
Но они всё равно не шаблоны. Если откинуть примитивные типы, то всё становится так же как в Java, дженерики - это НЕ кодогенерация, дженерики - это отличный синтаксический сахар над проверками типов времени компиляции. Но и только.
Это просто объяснить - все объекты в Java/C# являются наследниками общего предка Object.
В первых версиях языков (без дженериков) коллекции типа List хранили ссылки на Object и любой объект туда положенный доставался через метод Object Get( int i ) как Object и его надо было привести к тому типу который туда ложился, чтобы работать с ним дальше.
Так вот, дженерики это по большей части синтаксический сахар над тем, чтобы написать:
List<MyObject> list и при этом компилятор запретит вызывать Add не от MyObject или его наследника, а Get вернет сразу не Object, а MyObject, сам выполнить преобразование типа (причем даже не нужно делать проверки валидности на этом этапе, см. ниже).
Важно то, что List<MyOtherObject> даже не связанный с MyObject наследованием будет в рантайме пользоваться абсолютно тем же машинным кодом скомпилированной один раз коллекции List<T>, потому что все ссылки одинаковы, все есть наследники Object, а т.к. компилятор в компил-тайме запретил ложить в List<MyOtherObject> что либо иное, нежели MyOtherObject, то он может быть уверен, что там лежит именно оно, а Get даже никакой проверки типов делать не обязан - заранее известно что каст к MyOtherObject пройдёт без ошибок.
Причём из кода это действительно дико похоже и в объявлении и в использовании на std::list<T>, но суть сильно другая, до мощи кодогенерации шаблонов С++ тут как до луны пешком.
Например, т.к. дженериковый класс MyClass<T> ничего не знает о типе T, то он не может делать никаких предположений, кроме того что там лежит Object. Сам как таковой.
Чтобы заставить MyClass<T> "видеть" методы у шаблонотипа надо явно указать от кого он производится: class MyClass<T> where T : MyNode, только тогда дженериковый тип MyClass<T> сможет использовать методы из MyNode, но и только наследников от MyNode в него можно будет положить.
Как то так. В общем это не кодогенерация, но и то, что в своих рамках это очень мощный и нужный сахар - верно. Более того, там даже рождаются на стыке этих ограничений концепции неизвестные С++, причём невозможные в нём к воспроизведению. Например List<Parent> можно передать в метод принимающий List<Child>, если метод читает из списка, но нельзя - если пишет. И наоборот - в метод принимающий List<Child> можно передать List<Parent>, если метод пишет в список, но не читает.
На бытовом языке: в корзину фруктов всегда можно положить грушу, но из корзины фруктов не всегда можно вытащить грушу.
Зато из корзины груш всегда берешь фрукт, но не любой фрукт можно положить в корзину груш.

[warlock66613]

aa_dav, то что вы написали относится к джавовским недодженерикам, в случае настоящих дженериков как в C# всё примерно наоборот по всем пунктам.

-- 10.02.2017, 19:38 --

Вкратце:

aa_dav в сообщении #1191494 писал(а):

все объекты в Java/C# являются наследниками общего предка Object

Не совсем так.

aa_dav в сообщении #1191494 писал(а):

дженерики это по большей части синтаксический сахар

Нет.

aa_dav в сообщении #1191494 писал(а):

Важно то, что List<MyOtherObject> даже не связанный с MyObject наследованием будет в рантайме пользоваться абсолютно тем же машинным кодом скомпилированной один раз коллекции List<T>

Нет.

aa_dav в сообщении #1191494 писал(а):

до мощи кодогенерации шаблонов С++ тут как до луны пешком

В определённом смысле наоборот: в случае дженериков нет этого страшного промежуточного кода, от которого программисту прилетают чудовищные сообщения об ошибках.

warlock66613 в сообщении #1191502 писал(а):

Например, т.к. дженериковый класс MyClass<T> ничего не знает о типе T, то он не может делать никаких предположений, кроме того что там лежит Object. Сам как таковой.

Знает.

aa_dav в сообщении #1191494 писал(а):

Чтобы заставить MyClass<T> "видеть" методы у шаблонотипа надо явно указать от кого он производится: class MyClass<T> where T : MyNode, только тогда дженериковый тип MyClass<T> сможет использовать методы из MyNode, но и только наследников от MyNode в него можно будет положить.

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

aa_dav в сообщении #1191494 писал(а):

Более того, там даже рождаются на стыке этих ограничений концепции неизвестные С++, причём невозможные в нём к воспроизведению. Например List<Parent> можно передать в метод принимающий List<Child>, если метод читает из списка, но нельзя - если пишет. И наоборот - в метод принимающий List<Child> можно передать List<Parent>, если метод пишет в список, но не читает.

Ковариантные и контравариантные параметры дженериков - концепция не новая, и работает она не совсем так, а если точнее совсем не так.

[aa_dav]

Подтверждения моим словам: https://msdn.microsoft.com/ru-ru/library/f4a6ta2h.aspx

Цитата:

Затем при каждом создании экземпляра построенного типа со ссылочным типом в качестве параметра, (независимо от того, какой это тип) среда выполнения снова использует созданную ранее специализированную версию универсального типа. Это возможно, потому что все ссылки имеют одинаковый размер.

Я выше сразу сказал, что не рассматриваю примитивные типы (и к этому еще действительно надо добавить структуры видимо) - для них действительно производится генерация совсем как в С++ для эффективности, но рассмотрим полный список отличий от шаблонов С++: https://msdn.microsoft.com/ru-ru/library/c6cyy67b.aspx
И понятно, что это решает лишь и только лишь вопрос эффективности. По своим возможностям же дженерики есть, были и остаются просто удобным сахаром над compile-time проверкой типов. Ничего подобного С++, кроме list<T> они не могут, правда могут чуть большее в этом плане, в силу вышесказанного (*вариантности даже на практике не нюхал, могу ошибаться)

[Munin]

aa_dav в сообщении #1191494 писал(а):

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

Ну а собственно, на практике большего и не надо. И про template-ы я говорил именно в смысле контейнеров стандартной библиотеки, как вы могли заметить. (Я бы ещё добавил алгоритмы, но их широкая публика не осваивает, и потому они менее значимы.)