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

32

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

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

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

java c# microsoft oracle

— 123iamking
источник

12

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

— Каяман

15

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

— GoatInTheMachine

3

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

— JacquesB

2

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

— Марк Роджерс

32

Для вашего же блага, не обращайте внимания на людей, которые считают, что язык должен иметь все возможности C ++, чтобы считаться «реальным» и «полным». Не обращайте внимания на людей, которые считают, что безопасность типов, безопасность памяти и четко определенное поведение являются «тренировочными колесами». Правильность становится наиболее важным аспектом программного обеспечения в большинстве отраслей, и люди, которые гордятся тем, что не заботятся об этом, скоро станут неактуальными.

— Теодорос Чатзигианнакис,

162

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

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

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

— Килиан Фот
источник

67

Это мой готовый ответ.

— Нил

71

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

— Нил

29

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

— Роберт Харви

12

@RobertHarvey Я на 100% согласен. Будучи долгое время программистом C ++, я скептически относился к автоматическому управлению памятью при переходе на C #. Как только я прошел через это, это было невероятно освобождающим - просто не волноваться об этом в 99% случаев. Это освободило мой ум, чтобы вместо этого думать о других проблемах.

— 17 из 26

8

Msgstr "Назначить любой объект любому другому без ограничений типа." ... Итак dynamic,?

— Артуро Торрес Санчес

34

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

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

[...]

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

[...]

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

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

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

— Йорг Миттаг
источник

18

По иронии судьбы, он не любит C точно по той же причине, по которой он любит C ++, он очень открыт, допускает много энергии и много ошибок.

— GreySage

8

Он считает C ++ более выразительным, чем Python

— benxyzzy,

12

@GreySage Это тоже привлекло мое внимание ... C слишком подвержен ошибкам, но C # не дает вам достаточно энергии? C это далеко от C ++? C # не имеет «небезопасных» углов, которые дают вам больше контроля? Интересная смесь мнений, это точно ...

— WernerCD

10

@WernerCD не может рассказать о небезопасных C #, но C и C ++ не имеют ничего общего, кроме того, что вы можете превратить базовый фрагмент C90 в действительный фрагмент C ++ - ish, от которого компилятор не захлебнется.

— Квентин

23

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

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

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

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

— GoatInTheMachine
источник

6

Я согласен с вашей позицией в последнем абзаце. C ++ должен называться «Фонтан эксплойтов».

— Калеб Мауэр

3

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

— Харрисон Пейн

12

Оглядываясь назад на архивы , кажется, что эта цитата была с 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.

— натуральный
источник

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

— user253751

1

@immibis Не намеренный удар по Java, но, черт возьми, правда? staticклассы кажутся такой примитивной особенностью; Я представлял себе, что они предшествовали инстанс-классам.

— Nat

2

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

— user253751

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

— Йирка Ханика

@JirkaHanika Да, я staticв любом случае не большой поклонник классов. Честно говоря, я выбрал это как функцию для вызова, потому что это казалось очень простой, примитивной частью C #; Я не считал, что они не были на Яве.

— Nat

3

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

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

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

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

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

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

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

— Уэс Толеман
источник

5

Это очень запутано. Указатели (в логическом смысле существуют в Java), вы просто не можете обойтись с ними. Весь смысл упрощения модели состоит в том, чтобы предоставить больше гарантий. Логика, что вы можете предположить больше о коде на языке, будет меньше ограничений назад. Больше ограничений -> больше гарантий.

— JimmyJames

1

@JimmyJames фраза означает, что, хотя все классы Java имеют неявную (yuck, btw) ссылочную семантику, вы не можете иметь фактический указатель. Например, нет способа получить «ссылку» на ссылку. Это наносит вред языку в нескольких местах, иногда требуя безумных обходных путей (посмотрите, Map.mergeкогда вы просто хотите обновить значение на карте).

— Квентин

3

@JimmyJames: Некоторые виды полезных гарантий практически не могут быть предложены без наложения определенных ограничений. Кроме того, некоторые полезные оптимизации могут потребовать наложения некоторых ограничений. Однако некоторые языки накладывают бессмысленные ограничения, которые не дают каких-либо полезных гарантий программистам и не требуют обязательной оптимизации. Некоторые ограничения просто плохие.

— суперкат

3

@JimmyJames: С другой стороны, некоторые из более фундаментальных ограничений Java и «безопасного режима» C # позволяют им дать очень полезную гарантию того, что C ++ не может: любая ссылка (что в C ++ будет указателем), которая когда-либо существовала Наблюдаемый для идентификации конкретного объекта никогда не будет наблюдаться для идентификации чего - либо еще .

— суперкат

3

Можете ли вы предоставить некоторые цитаты в поддержку вашего ответа? Например, AFAIK, на странице не упоминается const. Это делает упоминание «функциональное программирование», однако, язык , который он использует в качестве примера можно Scheme, которая является не чисто функциональным языком (на самом деле, разработчики схемы осторожны , чтобы избежать использования слова «функции» и говорить о " процедуры »), так что, похоже, он использует интерпретацию FP« первоклассных подпрограмм », а не« ссылочную прозрачность ».

— Йорг Миттаг

1

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

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

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

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

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

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

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

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

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

— Walfrat
источник

Реальная стоимость множественного наследования заключается в том, что невозможно обеспечить обе следующие гарантии: (1) Если член базового класса Bпереопределен в среднем классе M, то B«версия этого члена будет доступна только через M» переопределить; (2) учитывая любую ссылку на тип T, преобразование его в любой супертип и обратно Tприведет к ссылке, эквивалентной оригиналу. Обе эти гарантии полезны, и для поддержки множественного наследования потребуется отказаться хотя бы от одного.

— суперкат

-1

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

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

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

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

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

— Akumaburn
источник

это , кажется, не предлагает ничего существенного по точкам сделанных и объяснено в предыдущих 5 ответов

— комар

1

They exist not so much to protect the programmer from him/herself, but rather to protect the programmer from other programmers!

или это для защиты других программистов от программиста?

— Тобиа Тесан

@TobiaTesan Это тоже :)

— Akumaburn