Сообщение Re[17]: Кровавую баню луддитам от 26.04.2017 12:06
Изменено 26.04.2017 12:13 Философ
Re[17]: Кровавую баню луддитам
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Философ, Вы писали:
ARK>>>Я предлагаю явным образом ограничить использование подобных небезопасных вещей. Блоками "unsafe" и соответствующим ключом компиляции. Ядро и менеджер памяти компилировать с "-unsafe", а 95% остального кода — без.
Ф>>Многопоточность оградить блоком "unsafe"??? Удачи
ARK>Многопоточность (гонки) оградить borrow checker'ом.
Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?
Ф>>Ты похоже не понимаешь главного: ограничивая возможности подобным образом, ты не уменьшишь кол-во ошибок, ты заменишь одни ошибки на другие, например, NotNull указатели на объект изменят NullReferenceException на значительно более хитрую: неправильный объект приведёт к неправильным действиям и неправильному результату.
ARK>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".
Слово NULL меняем на слово "None"?
ARK>Здравствуйте, Философ, Вы писали:
ARK>>>Я предлагаю явным образом ограничить использование подобных небезопасных вещей. Блоками "unsafe" и соответствующим ключом компиляции. Ядро и менеджер памяти компилировать с "-unsafe", а 95% остального кода — без.
Ф>>Многопоточность оградить блоком "unsafe"??? Удачи
ARK>Многопоточность (гонки) оградить borrow checker'ом.
Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?
Ф>>Ты похоже не понимаешь главного: ограничивая возможности подобным образом, ты не уменьшишь кол-во ошибок, ты заменишь одни ошибки на другие, например, NotNull указатели на объект изменят NullReferenceException на значительно более хитрую: неправильный объект приведёт к неправильным действиям и неправильному результату.
ARK>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".
Слово NULL меняем на слово "None"?
Re[17]: Кровавую баню луддитам
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Философ, Вы писали:
ARK>>>Я предлагаю явным образом ограничить использование подобных небезопасных вещей. Блоками "unsafe" и соответствующим ключом компиляции. Ядро и менеджер памяти компилировать с "-unsafe", а 95% остального кода — без.
Ф>>Многопоточность оградить блоком "unsafe"??? Удачи
ARK>Многопоточность (гонки) оградить borrow checker'ом.
Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?
Ф>>Ты похоже не понимаешь главного: ограничивая возможности подобным образом, ты не уменьшишь кол-во ошибок, ты заменишь одни ошибки на другие, например, NotNull указатели на объект изменят NullReferenceException на значительно более хитрую: неправильный объект приведёт к неправильным действиям и неправильному результату.
ARK>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".
Слово NULL меняем на слово "None"?
if (parameter is MyObject)
{
parameter.CallMethod(); // можно! мы точно знаем, что пришел именно MyObject, а не None
}
Ты понимаешь, что в случае else мы будем либо исключение выбрасывать, либо делать что-то непотребное. Я, кстати, неоднократно сталкивался с людьми, которые всерьёз предлагали заменить выкидывания исключений типа InvalidArgumentException/ArgumentNullExcetption на return'ы: нет исключения — нет проблемы, пользователь не видит ошибку — всё хорошо. Не важно, что программа погоду в Африке считает, главное, она юзера сообщениями об ошибках не задалбывает.
ARK>Здравствуйте, Философ, Вы писали:
ARK>>>Я предлагаю явным образом ограничить использование подобных небезопасных вещей. Блоками "unsafe" и соответствующим ключом компиляции. Ядро и менеджер памяти компилировать с "-unsafe", а 95% остального кода — без.
Ф>>Многопоточность оградить блоком "unsafe"??? Удачи
ARK>Многопоточность (гонки) оградить borrow checker'ом.
Ничего не понял. Это кто такое, этот borrow checker? Типа Invok'а в главный поток что-то?
Ф>>Ты похоже не понимаешь главного: ограничивая возможности подобным образом, ты не уменьшишь кол-во ошибок, ты заменишь одни ошибки на другие, например, NotNull указатели на объект изменят NullReferenceException на значительно более хитрую: неправильный объект приведёт к неправильным действиям и неправильному результату.
ARK>Абсолютно и стопроцентно НЕТ. Это как раз именно ты не понимаешь. Я говорю о полном удалении из языка целых классов ошибок, а вовсе не о замене их на другие. И, кстати, именно NULL является прекрасной иллюстрацией — он может быть совершенно безопасно удален из языка, это не просто полностью бесполезная, это вредная функциональность. Нет никаких "неправильных объектов", есть либо конкретный правильный объект, либо явно заданное значение "None".
Слово NULL меняем на слово "None"?
if (parameter is MyObject)
{
parameter.CallMethod(); // можно! мы точно знаем, что пришел именно MyObject, а не None
}
Ты понимаешь, что в случае else мы будем либо исключение выбрасывать, либо делать что-то непотребное. Я, кстати, неоднократно сталкивался с людьми, которые всерьёз предлагали заменить выкидывания исключений типа InvalidArgumentException/ArgumentNullExcetption на return'ы: нет исключения — нет проблемы, пользователь не видит ошибку — всё хорошо. Не важно, что программа погоду в Африке считает, главное, она юзера сообщениями об ошибках не задалбывает.