Що означає це твердження про те, що 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 # і 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

• Вихідні змінні
• Узгодження шаблону
• Кортежі
• Деконструкція
• Локальні функції
• Роздільники цифр
• Бінарні літерали
• Ref повертається та місцевих жителів
• Узагальнені типи повернення асинхронізації
• Виробничі конструкції та фіналізатори
• Експресивні окуляри та сетери

C # 7.1

• Основний асинхрон
• Буквені вирази за замовчуванням
• Іменні елементи кортежу

- "C Sharp" , Вікіпедія (посилання та посилання видалено)

Напевно, зрозуміліше, що C # здавався наполовину мовою в цьому контексті, оскільки йому бракувало багато того, що C # є сьогодні. Дивно думати, що у нього навіть не було staticзанять!

Також не вистачало більше матеріалів, оскільки C # прив’язаний до .NET. Наприклад, WPF тоді ще не було; це все WinForms.

Він скаржився на відсутність мовних особливостей, що дозволяють чітко визначити контроль. До них відносяться інструменти для

• Підвищення незмінності (наприклад, constключове слово C ++ )
• Контроль терміну експлуатації та права власності на об'єкт
• Контроль використання пам'яті, стилю копіювання та розподілу пам'яті

Це нагадує мені одну з моїх критичних рішень щодо Java:

все є вказівником, але покажчики не існують.

У об'єктах C ++ вказівники та посилання - це три різних поняття з чіткою семантикою. У Java у вас просто псевдо-об’єкт-вказівник. Зв’язуючи ці та скасовуючи істинну семантику вказівника, об'єктна модель стає менш зрозумілою.

У чітко визначеній програмі C ++ програміст може очікувати, що посилання будуть дійсними та недійсними. Через свою спрощену модель Java не може давати однакових гарантій.

Симптоми цієї менш чіткої моделі включають нульовий малюнок об'єкта та умови йоди, такі як 5.equals(potentiallyNullIntegerReference).

Я погоджуюся з відповіддю @Kilian, але додаду деякі елементи.

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

Оскільки Java та C # працюють через віртуальну машину, то логічно очікується, що ви не можете робити саме те, що вам подобається, перебуваючи прямо в операційній системі, тому що ви, швидше за все, пошкодили щось у віртуальній машині. Крім того, що Java орієнтована як платформа агностик, це ще більше логіки.

2- Тони додатків не вимагають від вас таких матеріалів.

Є багато додатків, які вам дійсно не потрібні, щоб перекопати стільки деталей, але якщо ви робите це мовою, яка вимагає, щоб ви це робили, ви отримуєте:

• Більше ризиків мати помилки через ті непотрібні речі.
• Більше витрат на розробку, управління пам’яттю та тестування потребує часу і так грошей!

3- Мова виробляється на певний вибір вагомих витрат / використання / ризиків, як ... все.

За допомогою C ++ ви можете робити майже все, що завгодно, тобто вибір людей зі С ++. Однак чим більше є, тим більше вам потрібно впоратися.

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

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

Скільки разів ми, як програмісти, стикаємося з бібліотеками, які були вразливі з побоюванням у своїх методах кодування та дизайну, але які ми змушені були використовувати з тих чи інших причин?

Ці програми, як правило, мають відмінні риси старого процедурного методу програмування, відсутність інкапсуляції, велика кількість прямої пам’яті записує майже без помилок вловлювання чи обробки. Segfaults переслідують масу при спробі використовувати їх у будь-якому масштабному проекті.

Ось де такі мови, як Java та C #, надзвичайно корисні; це не те, що нам подобається те, що вони не дозволяють нам робити все акуратне, що роблять інші мови, це те, що нам подобається відсутність головних болів, які нам доведеться терпіти, тому що інші програмісти зловживають акуратними речами, які можуть використовувати інші мови робити.

Інтерфейси заслуговують на будь-який компроміс з точки зору пам’яті чи швидкості виконання, на мій погляд. Я сподіваюся, що ви можете побачити, що в будь-якому часі з обмеженою у часі критичною місією застосування, всі ті засоби захисту, правильне керування помилками і, як правило, впевнені, що пам'ять не перевіряється - це хороші речі!