Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Просто смотрю С++ и уже не кажется таким уж сложным, т.к. в C# навязано множество концепций, которые тоже не просты.
В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Язык C появился в 1972 году и до сих пор не оброс всем этим хламом. Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Известный факт: уже в версии 3.0 спека C# была раза в полтора толще спеки С++.
Но в освоении С# всё же проще, т.к. проектировался изначально для более прикладных целей.
Вообще, опасность, конечно же, есть — сейчас язык развивается community, и многие решения принимаются не на основе взвешенного вдумчивого анализа, а просто потому, что кому-то взбрело в голову их принять, а остальным не хватило упорства противостоять энтузиазму.
Многие фичи языка, добавленные в 7/8/9/10, плохо или никак работают друг с другом.
Например, те же Expression Trees не поддерживают почти ничего из добавленного после C# 3.0.
Какие-то провалы потихонечку подтягивают — вот, к примеру, async enumerable. До него сочетать async pattern и enumerable pattern было невозможно.
Но это происходит медленнее, чем добавление новых фич.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
S>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом.
А ты уверен, что хорошо знаешь все фичи последних версий C? Про _Generic слышал?
S>Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Я считаю, что C де факто умер и заменён С++. Кто его там развивает, зачем, это вообще непонятно. По сути сейчас это какое-то достаточным произвольным образом взятое подмножество С++ (с кучкой несовместимостей, я в курсе, сути это не меняет).
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Джава была убога ещё тогда, когда C++ застыл в развитии. В джава мире котлин выглядит довольно интересным, но после плюсов — тоже скучен и неудобен
Здравствуйте, Shmj, Вы писали:
vsb>>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
S>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом. Видимо потому что его взяли под покровительство люди, умеющие думать на десятилетия вперед — Национальный институт стандартов США и Международная организация по стандартизации.
Здравствуйте, vsb, Вы писали:
S>>Язык C появился в 1972 году и до сих пор не оброс всем этим хламом.
vsb>А ты уверен, что хорошо знаешь все фичи последних версий C? Про _Generic слышал?
При этом, на тех платформах, на которых кроме Си — ничего другого нет, там и Си хорошо если соответствует стандарту Си 89, или какой там был последний лохматый стандарт
Здравствуйте, Sinclair, Вы писали:
S>Но это происходит медленнее, чем добавление новых фич.
Ну много они добавили для увеличения скорости те же Span. Немерлисты так долго ждали и разочаровались в Source Generator и в PM. А вот Reles http://rsdn.org/forum/dotnet/7749568.flat
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
S>Просто смотрю С++ и уже не кажется таким уж сложным, т.к. в C# навязано множество концепций, которые тоже не просты.
S>Лет через 15 будет тот же вавилон, имхо.
S>Как то все по одному сценарию идет.
На самом то деле С# наверное уже сложнее. Одни деревья выражений чего стоят и еще больше хочется. Но все нововведения это увеличение скорости программирования и скорости выполнения.
Но вот читабельность пока значительно проще. Ну в конце то концов деньги то получать нужно не за сам факт программирования!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Marty, Вы писали:
M>При этом, на тех платформах, на которых кроме Си — ничего другого нет
Колво таких платформ уже исчезающе мало и стремительно уменьшается.
Здравствуйте, Serginio1, Вы писали:
S> Ну много они добавили для увеличения скорости те же Span.
При этом Span<> и Async несовместимы. Ну, это ещё можно простить. Но вот Span<> и генерики несовместимы; то есть нельзя построить тип, параметризованный каким-нибудь Span<int>.
Так что если вы хотите описать сигнатуру "функции, которая принимает Span<char> и возвращает нужный мне тип T", то использовать Func<Span<char>, T> нельзя — надо честно писать delegate T Parse<T>(Span<char> arg):
using System;
public class Program
{
public delegate T Parse<T>(ReadOnlySpan<char> span);
public static void Main()
{
Parse<DateTime> p = (ReadOnlySpan<char> c)=>DateTime.Parse(c);
Func<ReadOnlySpan<char>, DateTime> t = p; // oops!
}
}
никак не введут
Ну, не знаю. С одной стороны, роли нафиг не нужны при наличии static abstract members в интерфейсах.
С другой стороны, иногда хочется приклеить операторы к "чужим" типам.
Ну вот, скажем, если бы можно было как-то сделать B operator |(A value, Func<A, B> transform) => transform(value), то получился бы тот самый pipe operator, Math.PI | Math.Sin | Math.Cos == 1
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
читабельность прет! Надо больше сокращать! Долой синтаксический оверхед!
Ну в принципе то читабельно. Это с непривычки.
Но таких конструкций можно и на любом языке
Конечно скобочки проставить лучше
public int F() =>
(A is B b) && (b.C is C) ? C.D ?? 1:FalseToNet ;
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Нет, не заметил. Этот язык и всё остальное, что идёт к нему в комплекте, спроектированы так, чтобы сложность по возможности оставалась под капотом. Прямо чувствуется, что это один из принципов. Например, типичный программист не пишет алгоритмы и контейнеры, а пользуется ими. Можно всю жизнь программировать на Шарпе и не знать про ключевое слово `yield`. И не просто программировать, а продуктивно.
Что касается «старшего собрата», его нынешний дизайн определил человек, который этой границы в упор не видит. Достаточно прочесть знаменитую цитату про «методологически неверный» ООП.
А раз так, значит и сложность нечего сравнивать. Сама по себе она не решает.
Забыл сразу написать: вы сортировку в плюсах видели? Допустим, программисту надо отсортировать строки в файле. Чтобы успешно выполнить задачу, он уже должен осилить 1) концепцию итераторов и 2) дихотомию контейнеры/алгоритмы. А ведь это только вершина айсберга. Без неё можно было бы обойтись (и в других библиотеках обходились, однако стандартизировали самую упоротую). Но есть подводная часть айсберга, от которой трудно куда-то деться: например, контракт на разделение ответственности по управлению памятью. Про это программист тоже должен думать, знать и понимать, иначе он словит или утечку, или исключение.
Как можно после этого сравнивать толщину спецификаций? Какой в этом смысл? Сложность Шарпа упакована намного более разумно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Ну много они добавили для увеличения скорости те же Span. S>При этом Span<> и Async несовместимы. Ну, это ещё можно простить. Но вот Span<> и генерики несовместимы; то есть нельзя построить тип, параметризованный каким-нибудь Span<int>.
Ну стек и Async не совместимы Memory<T> S>Так что если вы хотите описать сигнатуру "функции, которая принимает Span<char> и возвращает нужный мне тип T", то использовать Func<Span<char>, T> нельзя — надо честно писать delegate T Parse<T>(Span<char> arg): S>
S>using System;
S>public class Program
S>{
S> public delegate T Parse<T>(ReadOnlySpan<char> span);
S> public static void Main()
S> {
S> Parse<DateTime> p = (ReadOnlySpan<char> c)=>DateTime.Parse(c);
S> Func<ReadOnlySpan<char>, DateTime> t = p; // oops!
S> }
S>}
S>
public static string Create<TState>(
int length, TState state, SpanAction<char, TState> action);
...
public delegate void SpanAction<T, in TArg>(Span<T> span, TArg arg);
Этот метод реализован для выделения строки, а затем предоставления доступного для записи промежутка, в который вы можете писать, чтобы заполнить содержимое строки во время ее создания. Обратите внимание, что в этом случае полезна только стековая природа Span<T>, гарантирующая, что span (который относится к внутреннему хранилищу строки) перестанет существовать до завершения конструктора строки, что делает невозможным использование span для изменения строки после завершения построения:
int length = ...;
Random rand = ...;
string id = string.Create(length, rand, (Span<char> chars, Random r) =>
{
for (int i = 0; chars.Length; i++)
{
chars[i] = (char)(r.Next(0, 10) + '0');
}
});
Теперь вы не только избежали выделения, но и записываете непосредственно в память строки в куче, что означает, что вы также избегаете копирования и вас не ограничивают ограничения по размеру стека.
никак не введут S>Ну, не знаю. С одной стороны, роли нафиг не нужны при наличии static abstract members в интерфейсах.
нее это как использоваие существующих операторов +,-,*,/,++, итд для алгеброических типов
S>С другой стороны, иногда хочется приклеить операторы к "чужим" типам. S>Ну вот, скажем, если бы можно было как-то сделать B operator |(A value, Func<A, B> transform) => transform(value), то получился бы тот самый pipe operator, Math.PI | Math.Sin | Math.Cos == 1
Ну вот Roles для этого и нужны
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата
эээ шта? КОГО ИМЕННО ты считаешь "старшим братом" C#? Жабу штоле??
S> но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Можно подумать, кого-то волнуют "начинающие с нуля"! Начинаешь — пиши на Васике и не прыгай!
S>Просто смотрю С++ и уже не кажется таким уж сложным
А, ну да... совсем простой! Если одни хелловорлды писать Ты чтоб так говорить, написал ХОТЬ ЧТО-ТО больше 10 тыщ строк?
Здравствуйте, Shmj, Вы писали:
S>Заметили ли вы, что C# уже не тот. Конечно, еще не догнал старшего собрата, но уже дофига концепций, которые вам могут показаться очевидными, но вот начинающим с нуля — доставят.
Здравствуйте, vsb, Вы писали:
vsb>В Java тоже сложности накручивают потихоньку. Видимо это жизненный цикл любого языка. Я бы с удовольствием писал на Java 1.4-подобном языке. Считаю, что больше этого ничего не нужно.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, rudzuk, Вы писали:
R>>Здравствуйте, Serginio1, Вы писали:
S>>> Но вот читабельность пока значительно проще.
R>>Ога-ога,
читабельность прет! Надо больше сокращать! Долой синтаксический оверхед! S> Ну в принципе то читабельно. Это с непривычки. S>Но таких конструкций можно и на любом языке S> Конечно скобочки проставить лучше S>
S> public int F() =>
S> (A is B b) && (b.C is C) ? C.D ?? 1:FalseToNet ;
S>
да дело не в скобках, а однобуквенных именах. Замени A,B,C,D на что нить типа Customer/Order/Price и всё нормально будет читаться.
