@sodda

Как-то давно, когда я еще только начинал изучать Лисп, я пробовал писать свои реализации стандартных функций.
Это казалось мне наиболее интересным.
И вот я решил написать функцию, которая будет находить наибольшее число в списке.
Написал: функция хоть и делала то, что надо, но была плохой.
На это мне тогда указал Catstail
Вот она.

Проблема в том, что функция bad тут вычисляется два раза.
Catstail тогда подсказал как надо.

Здесь все как надо. Хорошо, когда есть кому подсказать.
Исправлено, работает - вот и славно. Забыли.
Но внутри что-то не давало покоя. И через пару дней я решил загуглить и посмотреть как другие решали эту задачу.
И что я увидел? - Вопрос на StackOwerflow о том, как найти наибольшее число в списке.
И ответ был плохой функцией, которая вычисляет себя два раза. И никто не исправил и не указал на эту ошибку.
Человек так и пошел дальше с ошибочным представлением об этом алгоритме. А что, работает ведь?
Тут задумался - " А почему мы делаем именно так. Что разных людей заставляет приходить к одному и тому же ошибочному решению?"
Вот тогда я посмотрел впервые на проблему реально. Вместо того, чтобы пытаться поскорее бездумно решить проблему нужно посмотреть на ее причину. А причина проста - функция возвращает булево значение. Именно это заставляет писать неуклюжий ошибочный код: вместо того, чтобы обойти гору, человек начинает на нее лезть.
Но ларчик же просто открывается, если призадуматься на секунду.
Вместо велосипеда простой и понятный код, который решает поставленную задачу.
В тот момент я понял как и почему пишется так называемый быдло код и почему потом происходят разные проблемы с безопасностью
и утечками памяти.
Я думаю вот почему так важно изучать такие языки, как Lisp. Они наглядно дают это понять.

2

@helter

Причина - булева слепота!

Кстати, схема из-за #t и #f более ей подвержена, чем CL.

В принципе, это тоже велосипед - расписанная свёртка. Так-то это (reduce #'max list).

0

@sodda

Нужно было написать функцию именно самому.

В CL тоже есть T и F

0

@helter

Точнее, nil, а не f, но дело в том, что в CL булево значение ассоциировано с любым объектом, а в схеме - только с #t и #f. В CL истинное значение несёт сколько угодно дополнительной информации.

Булева слепота возникает из-за того, что собственно булево значение несёт мало информации - один бит. Поэтому до ветвления часто вычислено больше информации, чем нужно для принятия решения, и её надо протаскивать в ветки. По-моему, функции bad и good идеально это иллюстрируют. А функция grt - что неплохо и вовсе обойтись без ветвления.

0

@sodda

Это да. Там вместо nil есть void, но это немного другое.
Nil, кстати, тоже может быть опасен в неумелых руках.
например у нас есть вектор (Пишу на Clojure, так как там есть nil)

nil - это тоже просто значение.

Может возникнуть такая ситуация

nil - это отсутствие значения или значение в векторе?

Поэтому функции для доступа к элементам коллекций принимает второй необязательный аргумент.

Теперь точно ясно, что значения с индексом 4 нет в векторе.

А что в CL функция может вернуть не булево значение?

0

@helter

Вообще, стандарт пишет "generalized boolean", то есть теоретически может быть что угодно. Но сомневаюсь, что какая-нибудь реализация возвращает что-либо кроме t или nil.

Это я просто лишний раз прорекламировал дизайн языка, но для данных примеров это неважно. На CL эти решения выглядели бы аналогично, но их недостатком была бы рекурсия вместо цикла или reduce.

Ага, в CL известный пример - find со своими родственниками. У Грэма, что ли, было написано, что из-за этого лиспер может проронить скупую слезу. Если есть опасность найти nil, можно пользоваться другими функциями (member, position). А gethash, чтобы избежать аналогичной проблемы, вторым значением возвращает флаг "найдено?".


Неа. Там может быть строка "Nothing". Будет надёжно, если использовать объект, сгенерированный на ходу: генсим или свежую конс-ячейку.

Добавлено через 7 минут

0

@sodda

В Clojure тоже есть find.

Возвращать можно что угодно. "Nothing" - как пример был.

Null - это та вещь от которой нужно избавиться раз и навсегда.
Сам изобретатель этого null потом статью написал - "Null - ошибка ценой в миллион долларов"
В Rust, например, отказались от null поэтому и вместо этого используют перечисления Result, которое может иметь значение или возвращает ошибку. И перечисление Option, которое может иметь значение или возвращает None. Суть в том, что эти перечисления в любом случае нужно проверить на отсутствие ошибки или отсутствие результата: получить доступ к значению, если оно есть, иначе невозможно.

0

@helter

Я понимаю. "Nothing" точно так же не работает для всех списков, как не работает для них nil. И никакая другая строка. Я предполагаю, не зная Clojure, что универсальное решение для любых списков должно включать создание на лету уникального объекта.

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

Есть какая-то философская разница между None и null? Не знаю раста.

Конечно. Они же в качестве логических значений, поэтому естественно участвуют в ветвлениях. Которые необязательно if-ами делать. Вот, в котлине сделали монаду Option: ?..

0

@sodda

Безусловно. Но вероятность что так окажется "Nothing" куда ниже, чем то, что там будет nil.

Ну возможные проблемы мы уже затронули выше, когда не понятно значение это или нет. Lisp - это бестиповый язык. Тем более, что современные диалекты стремятся все к большей функциональности. Например в том же С++ с null возможны серьезные проблемы.

Безусловно. В самих словах, конечно, нет - None или Null - нет разницы.
Нов подходе она очевидна. None - это перечисление типа Option, а получить доступ к перечислениям не так-то просто, как я говорил. Для этого нужно использовать match или другие конструкции языка.

Например:

Не обработать результат None невозможно.
Если написать match без ветви None, то компилятор заругается.

Скорее всего из Rust пришла. В Rust это сахар для макроса try!

0

@korvin_

Это никак особо не мешает, вместо #t можно вернуть любое значение.

0

@helter

Во дела, мне почему-то казалось, что в качестве логических должны быть именно #f и #f. Завязываю про схему писать.

0

@korvin_

Отличие от CL только в том, что nil не является #f.

Добавлено через 5 минут
https://ideone.com/aQ19bT

0