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

[arseniiv]

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

Ничего подобного С++, кроме list<T> они не могут

А что там такое в C++ особенное с шаблонами бывает кроме того, что их параметрами могут быть целые числа? (Вот тут да, вот тут придётся заменять такие числа каким-нибудь специальным типом, с которым будет не очень удобно работать в смысле выписывания его подтипов, соответствующих тому или иному числу.)

Насчёт вариантности. Пусть $t <: u$ означает «$t$ — подтип $u$». Тогда пусть $t$ — тип с $n$ типами-параметрами. $t$ ковариантен (в языках это обозначается как out в тех местах, где это нужно обозначать) по $i$-му аргументу, если $t_i <: t'_i \Rightarrow t[\ldots,t_i,\ldots] <: t[\ldots,t'_i,\ldots]$, и контравариантен (in), если $t_i <: t'_i \Rightarrow t[\ldots,t'_i,\ldots] <: t[\ldots,t_i,\ldots]$ (и порой говорят, что инвариантен, если нет ни того, ни этого). Обозначения можно объяснить тем, что тип функций ковариантен по типу результата и контравариантен по типам аргументов.

Я специально не буду говорить, что это означает на практике, потому что это слишком много, и лучшие примеры должны существовать уже и так.

[warlock66613]

arseniiv в сообщении #1191567 писал(а):

А что там такое в C++ особенное с шаблонами бывает

Там бывает Александреску (Александреску. Современное проектирование на С++. (прямая ссылка на pdf))

-- 10.02.2017, 22:45 --

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

По своим возможностям же дженерики есть, были и остаются просто удобным сахаром над compile-time проверкой типов.

Нет, даже если оставаться в заданных вами рамках, вы не правы. Доказательство:

Используется синтаксис C#

public static Container<T> {
    public static T Value;
}

Если бы всё было как говорите вы, то Container<SomeClass1>.Value и Container<SomeClass2>.Value были бы в рантайме одной и той же переменной, но это не так.

-- 10.02.2017, 22:55 --

Ах да, и ещё один аргумент. Хотя это наверно можно формально назвать синтаксическим сахаром, но только формально. Я имею в виду автоматический вывод типов. Конечно, он сильно уступает выводу типов в Haskell, но всё равно очень и очень неплох.

[arseniiv]

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

Там бывает Александреску

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

-- Сб фев 11, 2017 00:09:13 --

Ага, вот вижу, вообще-то спецификация шаблонов мной упущена, хотя раньше помнил. Дженерики так по-своему не специализируешь (пока?). И bool как тип параметра — но его-то типами как раз представить опять же совсем просто.

[warlock66613]

arseniiv в сообщении #1191601 писал(а):

Дженерики так по-своему не специализируешь (пока?)

Вполне возможно, что даже не "пока".

-- 10.02.2017, 23:15 --

arseniiv, посмотрите третью главу ("Списки типов"), и, более конкретно, раздел 3.4. Вычисление длины списка (ну и дальше тоже весьма любопытно).

[arseniiv]

О, если я угадываю, о чём там речь, то тогда это действительно оно.

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

Ах да, и ещё один аргумент. Хотя это наверно можно формально назвать синтаксическим сахаром, но только формально. Я имею в виду автоматический вывод типов. Конечно, он сильно уступает выводу типов в Haskell, но всё равно очень и очень неплох.

Меня вообще немного смутило смешение вместе aa_dav системы типов языка и его рантайма. Они могут быть вообще ортогональны, если не рассматривать соответствие рантайма выбранной семантике языка. То, что тип может иметь типы-параметры (или значения-параметры) — это свойства системы типов. То, есть ли операции, позволяющие смешивать $t[a]$ и $t[b]$ для несравнимых по подтипированию $a, b$ и тому подобные — тоже её. А что у этого под капотом — ну так там никто не запрещает спускаться вообще на уровень процессора, хотя это будет уже и натягиванием. В частности, если большинство проверок типов остаётся только на компиляторе, я не вижу, чем это может быть плохо, разве что невозможностью иметь reflection.

-- Сб фев 11, 2017 00:47:27 --

Про списки типов: понятно, что если C++ позволяет с ними делать больше, чем C# — это хорошо, но обратная сторона может быть в том, не позволяет ли он чересчур много — например, если я напишу параметром какого-то шаблона Typelist<int, Typelist<char, bool> >, неправильно завершив список, или вообще напишу на месте списка не-список, насколько понятным будет ответ компилятора на такое безобразие, и будет ли он гарантированным? (Продолжу читать и узнаю.) При аналогичной ситуации хаскель, например, даст нам описать это так, чтобы сообщение об ошибке было гарантировано, и говорило именно о том, что не так (правда, я пока там видел только гетерогенные списки, у которых есть значения, и которые ради этих значений и нужны, а не просто типы-списки типов без значений, которые полезны ради самих типов-параметров, но реализация должна быть не сильно другой). В общем, детали-то тут, конечно, оффтопны.

-- Сб фев 11, 2017 00:53:52 --

Кстати, в C# и Java (тут — насколько я в курсе) нет синонимов типов — вот это уже печально. (Недавно в C# появились, но их можно писать только среди директив using, а не в любом месте. Этого мало.)

[EtCetera]

У C# много интересных возможностей, но вот в плане обобщенного программирования/метапрограммирования там все печально по сравнению с C++. Атмосфера C++ в этой области тоже довольно разрежена, бедна кислородом, полна ядовитых примесей... Но в ней можно дышать. И даже летать... низенько, правда. В атмосфере C# программист долго просуществовать не может, приходится то и дело выходить в рантайм и прибегать к обстоятельной рефлексии.

Александреску в данном своем проявлении уже слегка устарел или потерял актуальность. Списки типов без лишней возни реализуются с помощью variadic templates (std::tuple опять же), появилось множество новых вкусностей, доступных даже диабетикам. Относительно свежие веяния можно пронаблюдать на примере библиотеки с очаровательным названием Boost.Hana.

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

-- Пт фев 10, 2017 23:03:39 --

arseniiv в сообщении #1191605 писал(а):

Недавно в C# появились, но их можно писать только среди директив using, а не в любом месте.

Появились они довольно давно (если вообще не сначала были), а вот то, что действие такого синонима распространяется только на отдельный файл, очень печально, приходится одну и ту же "шапку" из синонимов копировать из файла в файл. В C++11 тем временем уже появились синонимы для шаблонов.

[Munin]

arseniiv в сообщении #1191601 писал(а):

За ссылку, конечно, спасибо, но можно пару примеров? А то я даже не знаю, где их там быстренько найти. :-)

Они там прямо с введения начинаются.

[arseniiv]

Ну хорошо-хорошо, специализация шаблонов действительно с введения (Assert).

[aa_dav]

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

Ну а собственно, на практике большего и не надо.

Не ну если только ради коллекций list<T>, то тогда вполне себе. Плюс, по сравнению с Java С# вообще имеет value type struct как таковые, что в матанном смысле ему тоже будет большой плюс.

[arseniiv]

Java тоже собирается вводить value types. Не знаю, насколько там всё продвинулось, но можно понять, почему так долго, раз они не были с самого начала.

-- Сб фев 11, 2017 15:27:36 --

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

Ну а собственно, на практике большего и не надо.

Кстати, тут я не согласен. Даже чисто вычислительные задачи могут выиграть от выразительности возможностей метапрограммирования языка. Например, можно сделать статическую проверку размерностей, можно нагенерировать кода для умножения тензоров малых порядков разных размерностей и (хотя тут не думаю, что C++ уже сможет) даже упростить такой код для каких-нибудь сложных выражений, если это возможно. Ну, тут только надо дать волю фантазии и, уверен, применение найдётся.

[aa_dav]

arseniiv в сообщении #1191694 писал(а):

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

Насколько мне известно разработчики Java крайне не любят изменение архитектуры виртуальной машины.
Т.е. они расширяют язык, добавляют новые синтаксические конструкции, но когда компилятор поработал и получил *.class-файл, то его сможет переварить виртуальная машина 10-летней давности всё на тех же ~50 командах виртуальной машины.
value type-ы же, насколько я понимаю, без апгрейда виртуальной машины сделать невозможно.

[arseniiv]

Не могу комментировать это, потому что совсем не в курсе. Но над этим точно работали.

[warlock66613]

arseniiv в сообщении #1191694 писал(а):

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

В C# с некоторых пор есть очень хорошие внеязыковые возможности в виде Roslyn (это compiler as service).

[aa_dav]

arseniiv в сообщении #1191759 писал(а):

Но над этим точно работали.

Работали, конечно.
На сайте Oracle есть документация по 3 версиям VM, - 6,7,8.
6 называется просто "JVM Secondary Edition", т.е. видимо что до 6-ой (а не деле 1.6) версии не было изменений вообще.
В 7-ой и 8-ой структура оглавления уже сильно отличается от 6-ой, поэтому я не смог их сравнить через утилиту сравнения текстов.
Но если судить по этой утилите, то между 7-ой и 8-ой версией по составу "машинных инструкций" в оглавлении разницы нет никакой, хотя некоторые немного перетусованы в оглавлении, но это не должно вводить в заблуждение.
Какие то есть изменения в "annotations & specifications", но если глядеть краем глаза, то тоже вижу только перестановку слов и смену регистров букв.

[arseniiv]

Так я и не говорил же, будто работа над ними как-то сказалась на опубликованных версиях спецификаций JVM и Java.