Код, который вы не поймете. Подборка вымерших языков программирования

Лет 15 назад анонимные структуры использовал...

Код, который вы не поймете. Подборка вымерших языков программирования

Такое считается?

Исходник, если не хочется переходить на godbolt

template<typename T>
int test(const T&)
{
    return sizeof(T);
}

int main()
{
    struct {int a; double b;} x;
    return test(x);
}

PS: чем лямбды не анонимные структуры с оператором круглые скобки?

Код, который вы не поймете. Подборка вымерших языков программирования

J# - это следующая попытка

Код, который вы не поймете. Подборка вымерших языков программирования

Он неплохо себя чувствовал исключительно за счёт законодательной монополии.

Код, который вы не поймете. Подборка вымерших языков программирования

Вы не поймёте язык, код на котором мы не покажем!

Как мы за 2 недели решили проблему найма

Речь про набор на кассу в макдональдс грустно вкусно и точка?

Калькулятор? Да его напишет кто угодно

Для чего может быть нужна точность π больше двух знаков после запятой?

Например, для траекторных вычислений космического аппарата в миссии на спутник Юпитера.

Делегаты в C# подробнее

Автору статьи загадка

Func<int> x = () => 1;
x += () => 2;
Console.WriteLine(x());

Какой будет результат, не запуская код?

Без этого статья будет не полной.

Болезнь «ООП головного мозга»

Слышали, слышали... Кстати, в каком она там состоянии в наше время-то?

Болезнь «ООП головного мозга»

Ржавым душком повеяло...

Болезнь «ООП головного мозга»

Опросы вносят искажения. Вряд ли кто-то прямо считал ошибки и вёл статистику.

Поэтому, во-первых, в ответах сказывается эвристика доступности: если оказываемое воздействие больше, то, скорее всего оно лучше запомнилось и считается более вероятным.

Во-вторых, ошибки типизации могут восприниматься как более постыдные, и о них можно и умолчать, ведь логические тоже есть.

В-третьих, не все ошибки типов ещё выстрелили :)

Болезнь «ООП головного мозга»

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

Надеюсь, аналогия понятна.

Что такое правильная документация проекта

Слабая документация обычно не от стиля архитектуры зависит, а от своевременного выделения административных и человеческих ресурсов зависит.

Можно к этому вопросу даже с другой стороны подойти: микросервисный стиль архитектуры поддерживать больнее без текстового описания архитектуры. Если у разработчика проект на компилируемом языке, то нестыковка интерфейса банально не может выстрелить: код просто не компилируется. А в мелкосервисах фиг поймёшь что там между сервисами ходит без детальной документации.

Что такое правильная документация проекта

Статья выглядит как хейт монолитных решений "в общем случае": для монолитов минусы выставляются, плюсы же заметаются под ковёр. Для микросервисов та же картина, но ровно наоборот: плюсы выпячиваются, минусы заметаются под ковёр.

С таким подходом можно легко влететь в ситуацию "микросервисного монолита", когда исключается главное достоинством микросервиса - заменяемость, при этом недостатки в виде высокой связности остаются. Зато обилие связей сервисов и необходимость обслуживания связей путём внедрения всяких мониторингов и прочих вспомогательных компонентов со своими связями ведёт к повышению хрупкости системы. Ну и поддержание обозримости системы в целом - тоже та ещё задача (схема БД одного сервиса простая, ага, а вот количество неявных связей между БД разных сервисов может очень сильно порадовать глаз в случае рефакторингов схем данных).

И да, монолит (в смысле все связи - in-process) тоже может быть модульным с нормальной архитектурой.

Ваши навыки больше ничего не значат

Этот вопрос не про знание или незнание названия нотации а про то, что надо иметь хотя бы какую-то теоретическую базу, чтобы хоть где-то это понятие встретилось в письменном виде.

Ваши навыки больше ничего не значат

С этого и надо было начинать. И не продолжать.

Точно то же самое можно говорить и про медиков, но стрёмно, авось припомнят.

Болезнь «ООП головного мозга»

Минимизироваться должна связка {количество компонентов, сложность каждого компонента, количество связей конкретного компонента, общее количество связей, длина пути между функционально связанными компонентами, наверняка что-то ещё}.

Архитектуру можно считать относительно успешной, если интегральный рост этих метрик медленнее, чем функциональность проекта.

Дальше может быть дискуссия как это всё считать, но я бы не хотел открывать этот ящик Пандоры.

Болезнь «ООП головного мозга»

... а потом не запутаться в их композировании обратно

Болезнь «ООП головного мозга»

Что-то созвучное с анекдотом "Разум на Земле - величина постоянная. А население растёт."

Болезнь «ООП головного мозга»

Скорее так: слишком простой код вряд ли будет полезным.