Что означает это утверждение о том, что C # и Java являются половиной языка? [закрыто]

В статье: Почему POCO , есть это предложение:

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

Я не понимаю, что он имеет в виду, хотя C # принадлежит Microsoft, а Java принадлежит Oracle , это не значит, что они владеют половиной языка, не так ли? Я не нашел никаких доказательств, чтобы доказать это предложение, и мне действительно интересно это. И еще более любопытно, что касается «для моей собственной защиты».

Собчак не говорит о корпоративной собственности. «Полу» язык, который он пропускает, - это все те вещи, которые вы не можете сделать на многих современных языках, хотя, будучи хорошо образованным специалистом по компьютерам, он знает, что они могут быть сделаны возможными: наследуйте от любого количества классов, как вам нравится. Присвойте любой объект любому другому без ограничений типа. Управляйте выделением и освобождением ресурсов вручную, вместо того, чтобы доверять компилятору и среде выполнения делать это за него.

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

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

Это довольно хорошо объясняется в оригинальном источнике цитаты :

Я решил узнать больше о C ++ и стал его преданным энтузиастом - это включает в себя мой интерес к тому, как этот язык, вероятно, будет развиваться. Более того, я заметил, что для разработки полезных библиотек нужны не самые настоящие, а самые современные методы , а не реальные приложения. Имея это в виду, я попытался написать пару своих собственных библиотек для разных целей (см. Мою страницу загрузки), и я также пытаюсь заглянуть через плечо разработчиков C ++ Boost (см. Мою страницу ссылок), чтобы узнать, что эти высокотехнологичные методы. Тратить время на разработку библиотек, которые должны быть общими и полезными одновременно, действительно сложно. Вот почему программисты никогда не прекращают учиться.

[...]

Я продолжаю играть с C ++ и методами написания надежного программного обеспечения. Чтобы получить более широкую перспективу в области надежного программного обеспечения, я решил потратить некоторое время на изучение Ады (и связанных с ней вещей), языка, который, кажется, полностью заброшен бизнесом, хотя именно Ада была действительно разработана для сложных и надежных системы. Я должен признать, что изучение Ады было действительно полезным для меня в том смысле, что оно позволило мне более свежо взглянуть на мои подходы к работе и развитию. Самое главное, что некоторые идеи из мира Ады могут быть более или менее непосредственно применены к C ++ с хорошими результатами в области надежности и корректности.

[...]

Хорошо я забыл Я поклялся однажды не изучать Java. Но я сделал. Ну, до такой степени, что позволяет мне читать и писать рабочий код. Я читал «Мышление в Java» (доступно онлайн, бесплатно) и «Базовая Java» (не онлайн, не бесплатно), меня тоже косвенно привлекали в некоторые разработки Java, и ... Ну, я не покупаю Это. Мне просто не нравится, когда кто-то дает мне половину языка и говорит, что это для моей собственной защиты. Это как бумажный молоток, сделанный легким, чтобы никто не поранил себя при ударе пальцем ... То же самое относится и к C #. Я выбираю стальную кувалду, чтобы быть уверенным, что когда я захочу поиграть в мачо, она выдержит.
Вопрос в том, почему так много людей используют его (Java, C # и т. Д.)? Хм ... Может быть, потому что это очень хорошо в некоторых местах. Но есть ситуации, когда и язык, и библиотека показывают, что они были разработаны скорее для апплетов (изначально), чем для того, чтобы стать полезными утилитами. Это просто обещает слишком много и дает слишком мало, как для всеобъемлющей технологии. Или как решение, которое может превзойти любую конкуренцию ..

Мне нравится C ++, когда нужна максимальная мощность и самая широкая перспектива. В местах, где выразительность C ++ не обязательна, такие языки, как Tcl или Python, кажется, отвечают всем требованиям. Они не только открыты в отношении своей эволюции, но их можно расширять и встраивать в зависимости от конкретных потребностей. Я вижу много возможностей мечтать в этих технологиях. Я также склоняюсь к тому, чтобы отказаться от C как языка для обычного программирования - это кажется разумным выбором только в качестве цели для генерации кода, в противном случае он слишком подвержен ошибкам. Сегодня Ада является моим вероятным вторым выбором для более серьезных проектов, при условии, что у меня есть свободный выбор (что, к сожалению, не всегда).

Другими словами, автору этой цитаты нравится C ++, ему не нравится Java, и он чувствует, что в Java отсутствует половина C ++. И это все, что есть в этой цитате.

Статья, на которую есть ссылка в блоге, который вы разместили, была удалена, поэтому трудно быть уверенным, но, как говорит Килиан, вполне вероятно, что когда он говорит «половина языка», он подразумевает, что C # и Java чувствуют себя как C ++, но с большим количеством функции и конструкции удалены, чтобы сделать их более легкими в использовании или более безопасными.

Еще в 2006 году, когда это было написано, когда C # был относительно молодым, а Java была во многих отношениях незрелой, и когда власть против безопасности казалась компромиссом, когда вы могли выбрать только один, это не было абсолютно необоснованной позицией ,

В наши дни такая позиция совсем не разумна. Просто подумав о основных языках, C # и Java достигли огромных успехов, позаимствовав функции из других языков (особенно функциональных) для продвижения написания безопасного кода. У нас также есть языки, такие как Rust и Swift, которые созданы для этого.

Если кто-то смотрит на язык свысока, потому что он держит тебя за руку, или говорит, что язык, который трудно использовать, это как-то хорошо, я бы взял все, что он сказал, с долей соли. Вам нужно только взглянуть на смущающее количество ошибок, обнаруженных в коде, от которого мы зависим каждый день, написанном самыми яркими умами в отрасли, которого было бы тривиально избежать, используя «безопасные» языки, чтобы понять почему.

Оглядываясь назад на архивы , кажется, что эта цитата была с 2003 года (несмотря на то, что статья ссылалась на это с 2006 года). В то время C # был в версии 1. x , и ему не хватало многих его современных функций :

Новые возможности

C # 2.0

• Дженерики
• Частичные типы
• Анонимные методы
• итераторы
• Обнуляемые типы
• Геттер / сеттер отдельная доступность
• Преобразование групп методов (делегаты)
• Совместная и противоречивая дисперсия для делегатов
• Статические классы
• Вывод делегата

C # 3.0

• Неявно типизированные локальные переменные
• Инициализаторы объектов и коллекций
• Автоматически реализованные свойства
• Анонимные типы
• Методы расширения
• Выражения запроса
• Лямбда-выражение
• Деревья выражений
• Частичные методы

C # 4.0

• Динамическое связывание
• Именованные и необязательные аргументы
• Общая ко-и контравариантность
• Встроенные типы взаимодействия («NoPIA»)

C # 5.0

• Асинхронные методы
• Атрибуты информации о вызывающем абоненте

C # 6.0

• Компилятор как услуга (Рослин)
• Импорт членов статического типа в пространство имен
• Фильтры исключений
• Жду в уловах / ваще блоков
• Авто инициализаторы свойства
• Значения по умолчанию для свойств только для получения
• Экспрессивные члены
• Нулевой пропагатор (условно-нулевой оператор, краткая проверка нуля)
• Строковая интерполяция
• имя оператора
• Инициализатор словаря

C # 7.0

• Выходные переменные
• Сопоставление с образцом
• Кортеж
• Деконструкция
• Локальные функции
• Цифровые разделители
• Двоичные литералы
• Реф возврат и местные жители
• Обобщенные асинхронные типы возврата
• Конструктивные выражения и финализаторы
• Экспрессивные телесные геттеры и сеттеры

C # 7.1

• Асинхронный основной
• Буквенные выражения по умолчанию
• Предполагаемые имена элементов кортежа

- "C Sharp" , Википедия (ссылки и ссылки удалены)

Вероятно, более понятно, что C # в этом контексте выглядел как полуразык, так как ему не хватало того, что есть в C # сегодня. Странно думать, что там даже не было staticзанятий!

Больше вещей не хватало, так как C # был привязан к .NET. Например, WPF тогда не было; это были все WinForms.

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

• Обеспечение неизменности (например, constключевое слово C ++ )
• Контроль времени жизни и владения объектом
• Контроль использования памяти, стиль копирования и выделения

Это напоминает мне одну из моих критических замечаний по поводу Java:

все указатель, но указатели не существуют.

В объектах C ++ указатели и ссылки представляют собой три различных понятия с четкой семантикой. В Java у вас просто есть псевдообъект-указатель. Сочетая их и избегая истинной семантики указателей, объектная модель менее ясна.

В четко определенной программе на C ++ программист может ожидать, что ссылки будут действительными и ненулевыми. Из-за своей упрощенной модели Java не может дать такие же гарантии.

Симптомы этой менее понятной модели включают шаблон нулевого объекта и такие условия как yoda 5.equals(potentiallyNullIntegerReference).

Я согласен с ответом @Kilian, но я добавлю некоторые элементы.

1- Запуск на виртуальной машине, а не на ОС

Поскольку Java и C # работают через виртуальную машину, логично ожидать, что вы не можете делать то, что хотите, когда работаете прямо в ОС, потому что вы можете что-то повредить в виртуальной машине. Более того, поскольку Java ориентирована на независимость от платформы, это еще более логично.

2 - Тонны приложений не требуют от вас подобных вещей.

Есть тонны приложений, которые действительно не нуждаются в том, чтобы вы разбирались с таким большим количеством деталей, но если вы делаете это на языке, который требует от вас, вы получаете:

• Больше риска иметь ошибки из-за этих ненужных вещей.
• Больше затрат на разработку, управление памятью и тестирование, это требует времени и денег!

3- Язык сделан на некоторый выбор, взвешивающий стоимость / использование / риски, как ... все.

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

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

Проще говоря, все ограничения в языках высокого уровня, таких как C # и Java, существуют для защиты программиста. Они существуют не столько для защиты программиста от самого себя, сколько для защиты программиста от других программистов!

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

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

Вот где языки, такие как Java и C #, чрезвычайно полезны; не то, что им нравится тот факт, что они не позволяют нам делать все аккуратные вещи, которые делают другие языки, это то, что мы испытываем недостаток головной боли, которую нам приходится терпеть, потому что другие программисты злоупотребляли бы теми аккуратными вещами, которые могут другие языки делать.

Интерфейсы, на мой взгляд, стоят какого-то компромисса с точки зрения памяти или скорости выполнения. Я надеюсь, что вы можете видеть, что в любом ограниченном по времени критически важном приложении все эти средства защиты, правильная обработка ошибок и, как правило, уверенность в том, что память не будет взломана, являются хорошими вещами!