Якщо null є поганим, чому сучасні мови його реалізують? [зачинено]

Я впевнений, що дизайнери таких мов, як Java або C # знали проблеми, пов'язані з наявністю нульових посилань (див. Чи справді нульові посилання погані? ). Також реалізація типу опції насправді не набагато складніша за нульові посилання.

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

Це просто через консерватизм - "в інших мовах це є, у нас його теж є ..."?

Відмова: Оскільки я особисто не знаю жодного дизайнера мови, будь-яка відповідь, яку я даю вам, буде умоглядною.

Від самого Тоні Хоара :

Я називаю це моєю помилкою в мільярд доларів. Це був винахід нульової посилання в 1965 році. Тоді я розробляв першу комплексну систему для посилань на об'єктно-орієнтованій мові (ALGOL W). Моя мета полягала в тому, щоб будь-яке використання посилань було абсолютно безпечним, а перевірка виконувалась компілятором автоматично. Але я не втримався від спокуси ввести нульову посилання просто тому, що це було так просто здійснити. Це призвело до незліченних помилок, уразливості та збоїв у системі, які, ймовірно, спричинили біль і шкоду в мільярд доларів за останні сорок років.

Наголос мій.

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

"Ми були після програмістів на C ++. Багато з них нам вдалося перетягнути приблизно на півдорозі до Ліспа". -Гуй Стіл, співавтор специфікації Java

(Джерело: http://www.paulgraham.com/icad.html )

І, звичайно, C ++ має null, оскільки C має null, і не потрібно вникати в історичний вплив C. C # витіснив J ++, що було впровадженням Java від Microsoft, і також замінив C ++ як мову вибору для розробки Windows, тому він міг отримати його з будь-якого.

EDIT Ось ще одна цитата Хоара, яку варто врахувати:

Мови програмування в цілому є набагато складнішими, ніж раніше: орієнтація на об'єкти, успадкування та інші особливості все ще не розглядаються з точки зору цілісної та науково обґрунтованої дисципліни чи теорії правильності . Мій оригінальний постулат, котрий я все життя дотримувався вченого, полягає в тому, що кожен використовує критерії коректності як засіб наближення до гідного дизайну мови програмування - той, який не встановлює пасток для своїх користувачів, а також тих, котрий різні компоненти програми чітко відповідають різним компонентам його специфікації, тож ви можете скласти обґрунтовану думку про це. [...] Інструменти, включаючи компілятор, повинні базуватися на певній теорії того, що означає написати правильну програму. - усне інтерв'ю історії Філіпа Л. Франа, 17 липня 2002 р., Кембридж, Англія; Інститут Чарльза Беббіджа, Університет Міннесоти. [ Http://www.cbi.umn.edu/oh/display.phtml?id=343]

Знову наголос мій. Sun / Oracle та Microsoft - це компанії, а суть будь-якої компанії - це гроші. Користь для них від того, що nullвони могли перевершити мінуси, або у них просто був занадто жорсткий термін, щоб повністю розглянути це питання. Як приклад різного мовного помилок, який, мабуть, стався через строки

Прикро, що Cloneable зламаний, але це трапляється. Оригінальні API API Java були зроблені дуже швидко в стислі терміни, щоб зустріти закриття вікна ринку. Оригінальна команда Java зробила неймовірну роботу, але не всі API є ідеальними. Клоніруемость - слабке місце, і я думаю, що люди повинні усвідомлювати його обмеження. -Джош Блох

(Джерело: http://www.artima.com/intv/bloch13.html )

Я впевнений, що дизайнери таких мов, як Java або C # знали проблеми, пов'язані з наявністю нульових посилань

Звичайно.

Також реалізація типу опції насправді не набагато складніша за нульові посилання.

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

Чому вони вирішили все-таки включити його?

Весь дизайн - це процес вибору серед безлічі тонко і грубо несумісних цілей; Я можу дати лише короткий ескіз лише кількох факторів, які були б враховані:

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

• Ознайомлення з існуючими користувачами C, C ++ та Java є важливим.

• Важлива легка сумісність із COM.

• Важлива легка сумісність з усіма іншими мовами .NET.

• Важлива легка взаємодія з базами даних.

• Послідовність семантики важлива; якщо у нас є посилання на TheKingOfFrance, що дорівнює нулю, це завжди означає "немає короля Франції прямо зараз", або це може означати також "Однозначно є король Франції; я просто не знаю, хто це зараз"? чи це може означати "саме поняття мати короля у Франції є безглуздим, тому навіть не задайте питання!"? Нуль може означати всі ці речі та інше в C #, і всі ці поняття є корисними.

• Вартість продуктивності важлива.

• Важливим є прихильність до статичного аналізу.

• Послідовність системи типів важлива; чи можемо ми завжди знати, що нерегульована посилання ніколи за жодних обставин не виявляється недійсною? А як щодо конструктора об'єкта з ненульовим полем опорного типу? А як щодо фіналізатора такого об’єкта, де об’єкт доопрацьовується, оскільки код, який повинен був заповнити посилання, кинув виняток ? Система типу, яка лежить вам щодо своїх гарантій, небезпечна.

• А як щодо послідовності семантики? Нульові значення поширюються при використанні, але нульові посилання кидають винятки, коли вони використовуються. Це непослідовно; це невідповідність виправдана якоюсь вигодою?

• Чи можемо ми реалізувати функцію, не порушуючи інших функцій? Які ще можливі майбутні функції виключає ця функція?

• Ви йдете на війну з вашою армією, а не з тією, яку вам хотілося б. Пам'ятайте, що у C # 1.0 не було дженериків, тому говорити про Maybe<T>альтернативу - це повний нестандарт. Чи повинно .NET прослідковуватись протягом двох років, поки команда виконання додала загальну інформацію, виключно для усунення нульових посилань?

• А як щодо узгодженості системи типів? Ви можете сказати Nullable<T>для будь-якого типу значення - ні, чекайте, це брехня. Ви не можете сказати Nullable<Nullable<T>>. Чи зможете ви? Якщо так, то яка його бажана семантика? Чи варто змусити всю систему типів мати спеціальний корпус саме для цієї функції?

І так далі. Ці рішення є складними.

Null служить дуже поважною метою представляти відсутність цінності.

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

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

Приклад, що виправдовує нулі:

Дата смерті, як правило, є нульовим полем. Можливі три ситуації з датою смерті. Або людина померла, і дата відома, людина померла, і дата невідома, або людина не померла, а тому дата смерті не існує.

Дата смерті також є полем DateTime і не має значення "невідомо" або "порожнє". У нього є дата за замовчуванням, яка з’являється, коли ви вносите новий час, який змінюється залежно від використовуваної мови, але технічно є ймовірність, що людина насправді загинув у той час і позначив би ваше "порожнє значення", якби ви використовувати дату за замовчуванням.

Дані повинні бути належним чином відображати ситуацію.

Людина померла дата смерті відома (9.3.1984)

Простий, "9.09.1984"

Людина померла дата смерті невідома

То що найкраще? Нульовий , "0/0/0000" або "01 / 01/1869 "(або все, що вказано за замовчуванням?)

Особа не померла, дата смерті не застосовується

То що найкраще? Нульовий , "0/0/0000" або "01 / 01/1869 "(або все, що вказано за замовчуванням?)

Тож давайте подумаємо про кожне значення над ...

• Нуль , це має наслідки та проблеми, з якими потрібно бути обережними, випадково намагаючись маніпулювати нею, не підтверджуючи, що спочатку це не нульово, наприклад, викине виняток, але це також найкраще відображає реальну ситуацію ... Якщо людина не загинула дата смерті не існує ... це нічого ... це недійсне ...
• 0/0/0000 , Це може бути добре в деяких мовах і навіть може бути відповідним поданням про відсутність дати. На жаль, деякі мови та валідація відкинуть це як недійсний час, що у багатьох випадках робить його недійсним.
• 1/1/1869 (або будь-яке значення для дати за замовчуванням) , проблема тут полягає в тому, що це стає складним в обробці. Ви можете використати це як свою відсутність значущості, за винятком того, що трапиться, якщо я хочу відфільтрувати всі свої записи, у яких я не маю дати смерті? Я міг легко відфільтрувати людей, які насправді померли в цю дату, що може спричинити проблеми з цілісністю даних.

Той факт , іноді ви чи потрібно не представляти нічого і впевнений , що іноді змінна типу добре працює, але часто типи змінних повинні бути в змозі уявити нічого.

Якщо у мене немає яблук, у мене є 0 яблук, але що робити, якщо я не знаю, скільки яблук у мене?

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

Я б не пішов так далеко, як "інші мови мають, ми також повинні його мати" ... як би це було якось іти в ногу з Джонісом. Ключовою особливістю будь-якої нової мови є можливість взаємодії з існуючими бібліотеками іншими мовами (читати: C). Оскільки C має нульові покажчики, то рівень інтероперабельності обов'язково потребує поняття null (або якийсь інший еквівалент "не існує", який вибухає при його використанні).

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

Але (особливо для Java та C # через терміни їх впровадження та цільової аудиторії) використання типів опцій для цього шару сумісності, ймовірно, може завдати шкоди, якби не торпедувало їх прийняття. Або тип опції передається повністю вгору, дратуючи пекло програмістів на C ++ середини до кінця 90-х - або шар взаємодії може викидати винятки, стикаючись з нулями, дратуючи пекло з програмістів C ++ середини до кінця 90-х. ..

Перш за все, я думаю, що всі ми можемо погодитись, що концепція недійсності необхідна. Є деякі ситуації, коли нам потрібно представляти відсутність інформації.

Дозволення nullпосилань (і покажчиків) - лише одна реалізація цієї концепції, і, можливо, найпопулярніша, хоча, як відомо, є проблеми: C, Java, Python, Ruby, PHP, JavaScript, ... всі використовують подібне null.

Чому? Ну, яка альтернатива?

У функціональних мовах, таких як Haskell, ви маєте Optionабо Maybeтип; однак ці основані на:

• параметричні типи
• алгебраїчні типи даних

Тепер, чи підтримували оригінали C, Java, Python, Ruby або PHP будь-яку з цих функцій? Ні. Недосконалі дженерики Java є останніми в історії мови, і я якось сумніваюся, що інші їх взагалі реалізують.

Там у вас є. nullлегко, параметричні алгебраїчні типи даних важче. Люди пішли на найпростішу альтернативу.

Нуль / нуль / ніхто сам по собі не є злим.

Якщо ви спостерігаєте за його оманливо названим відомим виступом "Помилка мільярда доларів", Тоні Хоар розповідає про те, як дозволити будь-якій змінній змогти визначити нуль було величезною помилкою. Альтернатива - використання параметрів - насправді не позбавляється від нульових посилань. Натомість це дозволяє вказати, які змінні можуть містити нульові, а які ні.

Власне кажучи, в сучасних мовах, які реалізують належну обробку винятків, помилки з нульовим відхиленням не відрізняються від будь-якого іншого винятку - ви знайдете це, ви виправите. Деякі альтернативи нульових посилань (наприклад, модель Null Object) приховують помилки, внаслідок чого речі мовчки виходять з ладу набагато пізніше. На мою думку, набагато краще швидко провалитися .

Тож виникає питання, чому мови не реалізують Options? Власне кажучи, імовірно найпопулярніша мова всіх часів C ++ має можливість визначати змінні об'єкта, які неможливо призначити NULL. Це рішення "нульової проблеми", про який Тоні Хоаре згадував у своєму виступі. Чому наступна найпопулярніша набрана мова, Java, не має її? Можна запитати, чому у нього загалом стільки вад , особливо в її типній системі. Я не думаю, що ви справді можете сказати, що мови систематично роблять цю помилку. Деякі так, деякі ні.

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

Наприклад, якщо я хочу написати простий скрипт, який працює з файлом, я можу написати псевдокод на зразок:

file = openfile("joebloggs.txt")

for line in file
{
  print(line)
}

і просто не вдасться, якщо joebloggs.txt не існує. Вся справа в тому, що для простих сценаріїв це, мабуть, нормально, і для багатьох ситуацій у складнішому коді я знаю, що він існує, і збій не відбудеться, тому змушує мене перевіряти відходи свого часу. Більш безпечні альтернативи досягають своєї безпеки, змушуючи мене правильно розбиратися зі станом потенційного відмови, але часто я цього не хочу робити, я просто хочу продовжувати.

Існує чітке, практичне використання покажчика NULL(або nil, або Nil, або null, Nothingабо, як воно називається, у вибраній вами мові).

Для тих мов, які не мають системи винятків (наприклад, C), нульовий вказівник може бути використаний як позначка помилки при поверненні вказівника. Наприклад:

char *buf = malloc(20);
if (!buf)
{
    perror("memory allocation failed");
    exit(1);
}

Тут NULLповернений з malloc(3)використовується як маркер відмови.

Якщо використовується в аргументах методу / функції, він може вказувати на використання аргументу за замовчуванням або ігнорувати вихідний аргумент. Приклад нижче.

Навіть для тих мов, що мають механізм винятку, нульовий покажчик може використовуватися як індикатор м'якої помилки (тобто помилок, які підлягають відшкодуванню), особливо коли обробка виключень є дорогою (наприклад, Objective-C):

NSError *err = nil;
NSString *content = [NSString stringWithContentsOfURL:sourceFile
                                         usedEncoding:NULL // This output is ignored
                                                error:&err];
if (!content) // If the object is null, we have a soft error to recover from
{
    fprintf(stderr, "error: %s\n", [[err localizedDescription] UTF8String]);
    if (!error) // Check if the parent method ignored the error argument
        *error = err;
    return nil; // Go back to parent layer, with another soft error.
}

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

Є два пов'язані, але трохи різні питання:

1. Чи повинні nullвзагалі існувати? Або завжди слід використовувати Maybe<T>там, де null корисний?

2. Чи повинні всі посилання бути нульовими? Якщо ні, що має бути типовим?

   Наявність явного оголошення нульових посилальних типів string?подібними або подібними дозволить уникнути більшості (але не всіх) nullпричин проблем , не надто відрізняючись від тих, до яких звикли програмісти.

Я принаймні погоджуюся з вами, що не всі посилання повинні бути зведені нанівець. Але уникнення нуля не обходиться без його складностей:

.NET ініціалізує всі поля до того, default<T>як до них вперше можна отримати доступ керованим кодом. Це означає, що для типів посилань вам потрібен nullабо щось еквівалентне, і типи значень можна ініціалізувати до якогось нуля без запущеного коду. Незважаючи на те, що вони мають серйозні недоліки, простота defaultініціалізації, можливо, переважала ці недоліки.

• Для полів екземпляра ви можете обійти цю проблему , вимагаючи ініціалізацію полів перед тим оголюючи thisпокажчик на керований код. Spec # пройшов цей маршрут, використовуючи інший синтаксис від ланцюга конструктора порівняно з C #.

• Для статичних полів забезпечити це складніше, якщо ви не ставите сильних обмежень щодо того, який код може працювати в ініціалізаторі полів, оскільки ви не можете просто приховати thisпокажчик.

• Як ініціалізувати масиви референтних типів? Розглянемо, List<T>який підтримується масивом, місткістю більшою за довжину. Решта елементів повинні мати певне значення.

Інша проблема полягає в тому, що він не дозволяє такі методи, як bool TryGetValue<T>(key, out T value)повернення default(T), valueніби вони нічого не знаходять. Хоча в цьому випадку легко стверджувати, що вихідний параметр - це поганий дизайн, в першу чергу, і цей метод повинен повернути дискримінаційний союз або, можливо, замість цього.

Усі ці проблеми можна вирішити, але це не так просто, як "заборонити нуль і все добре".

Більшість корисних мов програмування дозволяють записувати та читати елементи даних у довільних послідовностях, так що часто неможливо статистично визначити порядок, у якому читання та запис відбуватиметься до запуску програми. Є багато випадків, коли код насправді зберігатиме корисні дані у кожному слоті перед його читанням, але де довести це буде складно. Таким чином, часто буде потрібно запускати програми там, де було б хоча б теоретично можливо для коду спробувати прочитати щось, що ще не було написано з корисним значенням. Незалежно від того, чи законно це робити, чи ні, немає загального способу зупинити код від спроби. Питання лише в тому, що має статися, коли це відбувається.

Різні мови та системи застосовують різні підходи.

• Одним із підходів було б сказати, що будь-яка спроба прочитати щось не написане призведе до негайної помилки.

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

• Третій підхід - просто ігнорувати проблему і нехай все, що сталося, «природно» просто відбудеться.

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

Підхід №4 набагато безпечніший, ніж підхід №3, і загалом дешевший, ніж підходи №1 та №2. Тоді залишається питання про те, яким має бути значення за замовчуванням для еталонного типу. Для незмінних типів посилань у багатьох випадках має сенс визначити екземпляр за замовчуванням і сказати, що за замовчуванням для будь-якої змінної цього типу має бути посилання на цей екземпляр. Для змінних посилальних типів, однак, це не буде дуже корисно. Якщо буде зроблена спроба використовувати змінний тип посилання до того, як вона була написана, зазвичай не існує жодного безпечного курсу дій, окрім пастки в точці спроби використання.

Семантичний кажучи, якщо один має масив customersтипу Customer[20]і один спробу , Customer[4].GiveMoney(23)НЕ супроводжуються збережене нічого Customer[4], виконання матиме пастку. Можна стверджувати, що спроба читання Customer[4]повинна негайно GiveMoneyпотрапляти в пастку, а не чекати, поки не буде спроби коду , але є достатньо випадків, коли корисно прочитати слот, з’ясувати, що він не містить значення, а потім скористатися цим інформація про те, що спроба читання сама по собі виявляється невдалою, часто є великою неприємністю.

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