Здравствуйте, Sorc17, Вы писали:
S>Нет это претензия. Потому что сначала разработчики языка сделали только А а = new А(), а потом взяли и изменили синтаксис языка.
Синтаксис не изменили, а расширили. Оба варианта в случае не-анонимных типов равноценны. Другими словами, теперь переменную можно объявить больше чем одним способом.

S>И судя по ответам ниже на мой пост, теперь А а = new A() пишут только инвалиды, потому что var a вообще говоря лучше и правильней, чем A a.
Не "лучше и правильней", а "читабельней и короче". С точки зрения компилятора разницы нет. Весь вопрос в гайдлайнах и стиле, принятых в команде.

Здравствуйте, Sorc17, Вы писали:

S>И возвращаясь к исходной мысли: через 5 ну может 10 лет таких нововведений, язык превратится в неюзабельнную свалку конструкций, и любой начинающий программист будет вынужден иметь многолетний опыт работы на нем, чтобы наконец-то научиться всеми ими пользоваться на практике, а значит разрабатывать качественные приложения.

Программист на то и программист, чтобы быть умным и во всем разбираться. Это элитная профессия для творческих людей. Каждая программа — произведение искусства. И это действительно так — по уровню сложности программа вполне сравнима с хорошей книгой или фильмом, где продумана каждая мелочь, где есть свои внутренние законы гармонии, которые может чувстовать в полной мере только разработчик, потративший много времени на проектирование и создание кода; случайный человек с улицы не может и не должен сразу же разобраться в коде, как невозможно понять и прочувствовать книгу, просто пролистав оглавление.

А если все будет слишком просто — то профессия программиста быстро откатится на уровень тупого эникейщика. Работяги, который будет тупо брать тупое формализованное ТЗ, тупо вбивать код по жестким правилам, и все будут довольны, особенно начальство, т.к. платить такому "специалисту" можно будет раз в 10 меньше.

Вы этого хотите?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Курилка, Вы писали:

К>>Ну яб сказал, что для язык может быть (не)удобен для решения задач, на которые он заточен, но при условии наличия головы у автора, который бы выражал на нём необходимые сущности.
S>И при условии наличия средств выражения на нём необходимых сущностей
S>На классическом бейсике адски трудно писать программы, т.к. нет даже понятия процедур. Точнее есть, но нет отдельного контекста, так что замутить рекурсию на нём невозможно.

S>На SQL нет встроенного способа декомпозиции задач. К примеру, я могу создать 2 view
S>

S>create view DelayedProjects as select * from projects where actualCompletionDate > estimatedCompletionDate
S>create view DelayedTasks as select from tasks where actualCompletionDate > estimatedCompletionDate
S>

S>но не могу определить функцию Delayed(), которая бы принимала реляцию с полями actualCompletionDate и estimatedCompletionDate, и возвращала реляцию, удовлетворяющую этому условию.

S>Если в вашем языке нет шаблонов/дженериков, то досвиданья такие сущности, как обобщённые коллекции.
S>Так что не только в голове дело.

Обобщенные коллекции (помимо шаблонов) в С++ можно сделать еще двумя способами:
1) Макросами (собственно, Страуструп так сначала и сделал)
2) С помощью наследования от какого-нибудь t_VirtualIterator

Про всякие Питоны не говорю — там как-то само получается.
Так что дело таки в голове.

Здравствуйте, alpha21264, Вы писали:

A>Обобщенные коллекции (помимо шаблонов) в С++ можно сделать еще двумя способами:
A>1) Макросами (собственно, Страуструп так сначала и сделал)
Да ладно. На макросах даже обобщённый max(a, b) нормально не сделаешь.
A>2) С помощью наследования от какого-нибудь t_VirtualIterator
Не понял. Кого именно вы хотите отнаследовать от t_VirtualIterator?
A>Про всякие Питоны не говорю — там как-то само получается.
Это про которые динамически типизированы?
A>Так что дело таки в голове.
Дело таки в языке.

Здравствуйте, x-code, Вы писали:

XC>А если все будет слишком просто — то профессия программиста быстро откатится на уровень тупого эникейщика. Работяги, который будет тупо брать тупое формализованное ТЗ, тупо вбивать код по жестким правилам, и все будут довольны, особенно начальство, т.к. платить такому "специалисту" можно будет раз в 10 меньше.

XC>Вы этого хотите?

Постойте, но вы только что описали современную софтверную индустрию

Я придерживаюсь принципа "равномерной плотности" кода. Т.е. элементарные моменты пытаюсь максимально сжать, сложные моменты — расписать по длиннее.

Здравствуйте, Sorc17, Вы писали:


S>Не. Претензия в том что это они внесли изменения которые у меня вызвали батх дискомфорт: мне пришлось изменить своей привычке всегда писать A a писать var a.

Что значит "пришлось"? Из usb выскакивает гномик и лупит по пальцам всякий раз, когда вы пишете очередную простыню Super.Cool.MyNewFreshyStupidousClass aaa = new ...?

Здравствуйте, Sinclair, Вы писали:

A>>Про всякие Питоны не говорю — там как-то само получается.
S>Это про которые динамически типизированы?

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

Здравствуйте, x-code, Вы писали:

XC>баги
Нет.

XC>тупые попытки сделать язык программирования похожим на английский...
В конкурсе тупиц победили авторы кобола и 1С?

Здравствуйте, anokata, Вы писали:

A>вот и покажите языки которые обходятся минимумом сущностей

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

Какие возможности по уменьшению количества сущностей появились в С# 2.0 по сравнению с C# 1.0?

1) Генерики. Позволили писать типобезопасные универсальные алгоритмы.

2) yield'ы. Позволили записывать асинхронные задачи псевдосинхронным образом, что позволило сделать прозрачным порядок выполнения шагов и передачу данных между ними.

3) Анонимные делегаты. Позволили строить логику на геттерах, а не на сеттерах, путем замены хранения значения на хранение способа его получения (на лету или через автоматический кэш). Кардинально увеличили возможности по написанию универсальных решений.


Какие возможности по уменьшению количества сущностей появились в C# 3.5? Увы, никаких, все изменения это просто альтернативный способ записи уже имеющейся возможности, то бишь банальный синтаксический сахар. Соответственно язык развивается не туда.


При этом, хотя я не вижу способа кардинально повысить мощность языка по сравнению со вторым шарпом, но мелких улучшений способных сократить/упростить использование сущностей, можно предложить множество. Например, возможность записать, что переменная не может быть null'ом при ее декларации, возможность создания классов-заготовок, на основе которых можно создавать другие классы, но с измененными именами членов и т.п. Но в этом направлении в шарпе не делается ничего.

Здравствуйте, Sorc17, Вы писали:

S>Нет это претензия. Потому что сначала разработчики языка сделали только А а = new А(), а потом взяли и изменили синтаксис языка. И судя по ответам ниже на мой пост, теперь А а = new A() пишут только инвалиды, потому что var a вообще говоря лучше и правильней, чем A a.

Ошибки все делают. Причем сделанные ошибки лучше исправлять, чем не исправлять. Вот ты лично правишь баги в собственных программах?