Как стать автором
Обновить

Комментарии 35

… и не одного коммента.
в три раза мертвее мёртвого Delphi

таки да

Почему же, есть очень важные комментарии вида:


{TVCompound}

TVCompound = class (TValue)

Это самые лучшие комментарии из разряда таких:


# Increment value of i
i = i + 1

Без них ведь не разобраться.

Я очень рад, что вам оказалось не лень заглянуть в мой проект.

По секрету скажу, что комментарии вида {TVCompaund} IDE вставляет автоматически. На самом деле это маркер, который используется функцией автодополнения.

Тогда извините. Странная IDE, которая ориентируется по комментариям, а не по исходному коду. Но я Pascal в последний раз трогал 20 лет назад, тогда еще не было IDE с автодополнением. А сейчас и вообще синтаксис паскаля забыл.


На Лиспе писал немного, но тоже мало и очень давно. Чем вам вариант Clojure не угодил?

В Clojure особенных фатальных недостатков вроде нет, но много мелочей, которые не понравились (в том числе необходимость в Java Runtime). В сумме получается смена шила, на мыло.

теперь еще есть babashka - Native, fast starting Clojure interpreter for scripting

Лисп хорош тем, что на нем хорошо доказываются математические теоремы из теории операторов и предикатов. Плюс можно написать конвертор из какого-нибудь языка в лисп.
Меня тоже многим оттолкнул Common Lisp. Но я думал, для чего-то простого лучше подойдёт Scheme. Там и лексическая область видимости, и минимализм встроенных конструкций, и tailcall optimization, continuations. Система макросов позволяет создать любой удобный DSL со своими for, var, etc.
А сейчас вы так думаете?
(Я (не (фанат (лиспов))), но почему не guile?
Guile — расширение для Си, со всеми вытекающими последствиями в мировоззрении.

Меня от SBCL оттолкнуло в том числе то, что это древний код на Си. Я не могу в нём разобраться и не могу ничего исправить.

Хороший маркер годности языка для меня — регистрочувствительность. Если язык чувствителен к регистру, значит авторы исповедуют несовместимые с моими привычками подходы.

Ну и не стоит забывать NIH-синдром.
Регистрочувствительность в каком языке? العَرَبِيَّة это то же самое, что عَرَبِيّ? Каждый раз, когда мне говорят про «регистрочувствительность», я вижу три варианта: 7-битного неандертальца, человека с бНОПНЯ по CP-1251 или бездну юникода у которой нет дна.

Вы из какой категории?
Тут четыре варианта ответа.

1. Вы не видите решения проблемы, а потому отказываетесь от её решения. Но проблема никуда не девается.

2. Юникод действительно бездна, а потому плюём в неё, и постулируем поддержку кириллицы, латиницы и греческого (тут проблем нет). Это конечно некрасиво, но предпочтительнее чем упасть в бездну.

3. Юникод содержит какие-то правила приведения регистров. Лися использует встроенную в FreePascal реализацию этих правил — UnicodeUpperCase. Если возникает проблема, то это недоработка в Unicode (тут ничего не поделать) или библиотеках.

4. Если для какого-то языка не определены правила регистронезависимости, то можно просто писать идентификаторы в одном регистре.
… А можно не писать и спокойно жить вот с такой нотацией:

class Example():


example = Example()

Эх. Что-то тема для холивара настолько обсосанная, что даже аргументы вспоминать лень. Может быть по какому другому поводу поругаемся?

Вы где-то пишите лисп, а где то лис. Это опечатка и жаргонное имя лиспа?)

Это не «лис». Это «Лися» — название диалекта.
Надо было больше аллюзий на дефекты речи в названии. Например, «Лифифька»…
НЛО прилетело и опубликовало эту надпись здесь
Нет, не написать.

Но есть нюансы:
1. Если двусвязный список нужен ради списка, то есть встроенный тип.
2. Если двусвязный список нужен ради оптимизации, то никак. Оптимизация принесена в жертву прозрачности кода.
3. Если есть алгоритм, который принципиально работает только на двусвязных списках, то можно вывернуться. Размещать объекты во встроенном списке/хэш-таблице и использовать вместо указателей индексы/ключи.
«совсем каплю Оберона» любопытно, что вы имели в виду?
Оберон упомянут как источник крайней минималистичности. Например, индексация только целыми числами и от нуля. А «капля» потому, что минималистичность получилась выборочная.
(for i 5
; повторить пять раз i = 0..4
)
(for i 1..6
; повторить пять раз i = 1..5
)

Если первое ещё можно понять, то вот ко второму есть вопрос… Почему до пяти, а не до шести?

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

Есть в Паскале одна особенность
for i := 0 to Count - 1 do ...

Вот это "-1" есть почти всегда. В Лисе, соответственно, этот "-1" не появляется.

Допустим нам надо итерировать по индексам списка начиная с 2
(var L \(0 1 2 3))
(for i (range 2 (length L)) тело цикла)

Функция RANGE в данном случае вернёт 2..4 и итерация выполнится по индексам 2 и 3.
2. Перезапуски
Обработчик исключения может внести изменения в состояние программы и послать команду перезапуска коду, сгенерировавшему исключение. Эффект от применения аналогичен использованию оператора GOTO для перехода из функции в функцию.

Не знаком с лиспом, но. Перезапуск, на мой взгляд, отличная штука для работы откатом транзакции в бд. Представьте, начали вы транзакцию, что-то делаете, затем делаете commit. А commit выясняет что те данные которые вы использовали — кто-то другой поменял пока вы были в рамках транзакции. И вот язык может взять и перезапустить код к месту начала транзакции, с откатом значений всех локальных переменных. Это, понятно, перспективная разработка, но я думаю это было бы круто.
Дело в том, что в лиспе «перезапуск» это не просто возможность повторно запустить код. Это возможность управлять запуском сбойных участков, из кода, который находится на произвольное количество уровней выше по стеку вызовов. Сложно придумать очевидный способ использования такого механизма.

Возможность перезапуска кода, находящегося на один уровень ниже, как и во всех языках, конечно есть и в Лисе. Оператор TRY, перехватывающий исключения, предусмотрен.

Мне одному показалось, что здесь программы в императивном стиле написаны на функциональном языке (императивщину записывать, имхо, удобней не стало)? Вознакает вопрос: в чем профит?

На самом деле в разделе «Использование» приведена одна императивная программа и две функциональных.

Императивщину записывать действительно удобнее не стало, но её стало удобнее отлаживать, благодаря решению ПРОБЛЕМЫ-1 (и проблемы-2).
Вопрос регистрозависимости было бы логичнее решить на уровне автокомплита и поиска в редакторе кода, а не на уровне языка.
Сначала можно зайти на Википедию на страницу Лиспа. Осмотреть раздел «Диалекты». Прочитать краткое введение к каждому. И осознать, что на вкус и цвет все фломастеры разные.

Я бы на вашем месте чуть внимательнее прочитал бы раздел о диалекте Racket. Мне кажется, он бы вам понравился, не в последнюю очередь потому, что в нём есть возможность вволю проявить синдром NIH легко создавать новые диалекты лиспа, и даже использовать в одном проекте несколько диалектов.

Racket действительно показался мне наиболее привлекательным, но он всё равно использует присваивание указателей. Проблема с побочными эффектами при попытке написать императивный код не решается.

Возможно я просто недопонял документацию, поэтому спрошу.
(var S1 (list (record :slot1 (list 1))))
(var S2)
(set S2 S1)
(set (elt S2 0 :slot1 0) 2)

Здесь есть структура S1 — список внутри записи внутри списка.
Структура S1 присваивается переменной S2.
Внутри S2 изменяется одно значение.

Лися гарантирует, что S1 не будет затронута ни при каких обстоятельствах.

Вопрос: что будет в Racket?

Racket тоже в каком-то смысле это гарантирует. Во-первых, начиная с довольно давнего времени (2007 год) cons в Racket иммутабельные, хотя есть языки, в которых это не так (например, в #lang sicp есть set-car! и set-cdr!, а сами cons имеют тип mcons, т.е. mutable cons). Во-вторых, поменять структуру тоже не получится, можно скопировать с изменением поля, хотя опять-таки никто вам не мешает сделать пачку макросов, которые будут вам давать мутабельные структуры.

Да, через макросы и иммутабельные структуры действительно можно было сделать. Но уже поздно.
Но уже поздно.

Ну и ладно, даёшь больше лиспов, хороших и разных :)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории