Джентельменский набор ЯП

> МК-61

Начинал с МК-54, но паять ничего не паял.

> лисп <...> Теперь болезнь запущена и я бы прописал этому языку эвтаназию. Из гуманизма.

согласен, хотя может какие-то идеи оттуда взять можно

> Дык если почему в первом случае мы можем доказывать свойства (++), а во тором нет?

Хотя бы потому, что в первом случае в списке целых случайно не окажется строка (компилятор не позволит), а во втором -- может оказаться.

/me затарился литературой по питону и яве,

чето творить тянет)

> Альтернатива есть?
Увы...

> То что тебе в чем-то открылись глаза по мере знакомства с лиспом ни о чем не говорит абсолютно, точно также откроютсяглаза на любой язык или платформу. Идеала увы нет.

Дельфи меня не настолько разочаровал. Хотя я пользуюсь и лиспом для задач кодогенерации и я не пытался переделывать на Дельфи те задачи, которые я делаю на лиспе. Так что я не могу сравнить.

> Мое мнение очень простое: у лиспа есть приемущества, которые с лихвой перекывают перечислнные тобой недостатки.

Раньше я тоже так думал. Теперь я думаю по другому: у лиспа есть недостатки, которые по большей части компенсируют его достоинства. Именно "практически", т.е., в контексте реальной деятельности. Конечно, это зависит от предметной области, но я думаю, что таких областей много. Да, в лиспе можно многое (не всё!) переопределить. Но при этом всегда будут потери - переопределённая фича не будет взаимодействовать с остальной средой так же хорошо, как родная. Всё же лисп имеет целостный дизайн. Усилия, которые я трачу на исправление лиспа (и изучение чужих работ в этом направлении) велики и отнимают довольно жирный кусок моего времени, поскольку стремление делать качественные исправления/расширения ставит сложные дизайнерские задачи. А моя задача не состоит в том, чтобы исправлять лисп. У меня есть производственные задачи.

> Lisp лучше C++ как язык и как платформа
Как язык - да. Как платформа - сомнительно. FFI не стандартизован. Есть ограничения на работу с FFI в многонитевом режиме (и сама многонитевость тоже не стандартизована). Я не скажу, что я потратил много времени, но я не понял, как мне сделать многонитевый сервер fuse на SBCL. Для хорошей (в практическом смысле) платформы я бы погуглил или воспользовался apt-ом и решил бы вопрос за 5 минут. А так мне пришлось делать биндинги к fuse хотя бы с ограниченным функционалом и теперь я буду вынужден их поддерживать, если вообще не брошу этот проект). Кроме того, в SBCL периодически выявляются довольно нехорошие баги. Поэтому надёжность SBCL как платформы тоже спорна.

> Наличие в Pascal синтакического сахара из коробки -- не аргумент
Я раньше тоже так думал. Теперь я считаю, что наличие сахара из коробки - это довольно сильный аргумент. Иначе нечем объяснить успех Python, который, как я понял, как раз и является урезанной и подслащённой версией лиспа? При том, что Python имеет более слабый дизайн рантайм-среды, работает намного медленнее и не имеет макросов, Python сегодня популярнее, чем CL.

Если учесть потери времени на разработку своего сахара и освоение всех сахаров, которые уже схимичили до тебя и которые тебе встретятся в чужом коде, то наличие сахара в коробке может оказаться важным. Pascal, как говорят в рекламе, "позволяет сосредоточиться непосредственно на решении производственной задачи".

> http://common-lisp.net/project/cl-dwim/
Спасибо, посмотрю. Частью библиотек из этого списка я уже пользуюсь.

[про полиморфную инициализацию]
> ты просто с++ не знаешь, такое "соглашение" пишется в 20 строчек, я даже на ЛОРе постил такую программку
Наверняка, 20 строчек занимает только сам паровоз. И плюс к тому, нужно ещё по тележке для каждого нового класса или хотя бы для каждой новой иерархии. Хорошо, если эта тележка - не класс-обёртка :)

Особенно весело это будет в случае чужих и/или шаблонных классов. Я всё же немного знаю С++ и именно разочарование в нём в своё время привело меня к лиспу :) В Object Pascal на эти случаи сделаны достаточно разумные и общие умолчания, которые позволяют не терять время на постоянную возню с этими вопросами и не загромождать код костылями.

Хотя, если всё же нужен язык класса лиспа, то я бы посмотрел на clojure. Я этого не делаю, потому что, во-первых, clojure ещё находится в процессе становления, а во-вторых, я не работаю на платформе java.

> И плюс к тому, нужно ещё по тележке для каждого нового класса или хотя бы для каждой новой иерархии.

НЕ нужно, они генерятся компилятором (в т.ч. для тех иерархий, которых не было в момент определения) Короче то, что в ObjPas из коробки, тут ты можешь сам сделать в 20 строк, и это -- как раз идеал.

А вот как быть в паскале, если ты хочешь, что Object (или как там называется суперкорень) имел пару определенных *тобой* полей? В плюсах это реально.

(но вообще с++ не катит как "язык мечты", как минимум ему нужна ресинтаксификация и усиленная верификация)

Вообще слова "синтаксический сахар" по-моему уводят внимание от главного в языке -- встроенного фреймоврка кодогенерации и верификации.

> Да, в лиспе можно многое (не всё!) переопределить.

Все я думаю переопределять смысла не имеет.

> Но при этом всегда будут потери - переопределённая фича не будет взаимодействовать с остальной средой так же хорошо, как родная.

1. По-моему это как раз основной критерий качества языка.

2. Здесь на самом деле нужно копать.

> А вот как быть в паскале, если ты хочешь, что Object (или как там называется суперкорень) имел пару определенных *тобой* полей? В плюсах это реально.

> НЕ нужно, они генерятся компилятором (в т.ч. для тех иерархий, которых не было в момент определения) Короче то, что в ObjPas из коробки, тут ты можешь сам сделать в 20 строк, и это -- как раз идеал.

Или я не знаю С++, или тут что-то не так. Можно ли на это посмотреть?
Хотя я всё равно не начну любить плюсы, конечно :)

> Вообще слова "синтаксический сахар" по-моему уводят внимание от главного в языке -- встроенного фреймоврка кодогенерации и верификации.
В языке нет чего-то одного главного. Качество определяется совокупностью свойств. А кодогенерацию/верификацию можно делать на любом языке, просто она не будет так же хорошо интегрирована, как в случае лиспа. Шаблоны и макросы плюсов я не считаю кодогенерацией, т.к. слишком много нелепых ограничений.

Вот ( там правда есть лишнее слово boxed в инициализаторе, но насколько я знаю в с++0х можно сделать без него, или в текущем с++ Something* arr(1, "asdf", 3.1415926); )

http://www.linux.org.ru/view-message.jsp?msgid=3265209#3266221

> В языке нет чего-то одного главного. Качество определяется совокупностью свойств.

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

Я так предлагаю такие:

1. Возможность задавать свой синтаксис (в определенных пределах).

2. Система типов (включая информацию, что относительно чего локально)

3. Type inference (я думаю нужна усеченная, Хиндли-Милнер это слишком много... хотя...)

4. Кодогенерация, основанная на системе типов.

5. Верификация, основанная на системе типов (типичная из с++, дополненная например "нельзя отдавать адрес локальной переменной наружу функции")

6. Вычисления во время компиляции (например, скомпилить регулярное выражение, а не просто "x+2+3" => "x+5" ).

7. Вычисления над типами во время компиляции.

8. Вычисление и выдача сообщений об ошибках, определенных пользователем.

> А кодогенерацию/верификацию можно делать на любом языке, просто она не будет так же хорошо интегрирована, как в случае лиспа.

Спорный вопрос. В лиспе есть доступ к тому, что в обычных языках называется AST, но мне сильно кажется, что кодогенерация не должна быть на основе AST. То есть она должна быть через прокладку.

> Шаблоны и макросы плюсов я не считаю кодогенерацией, т.к. слишком много нелепых ограничений.

Список ограничений в студию. Поскольку я тут не войну веду, разрешается сказать лишнее, но доказывать что это не ограничение -- я возможно не буду.

Ах да, забыл еще пункт, который для меня очевиден...

0. Работа в (виртуальной) машине "плоское сегментированное адресное пространство с указателями" (это виртуальная машина Си и с++)

В языках, достойных внимания (с++, cyclone, D, хаскель) имеем... и тут я заленился писать. К тому же, лучше наверно на форуме поспрашивать насчет хаскеля и D, я их не до конца изучил.

Хотя честно говоря этот пункт 0 не такой обязательный для других... но это длинный разговор.

Качество - это производительность труда при разработке в заданной области. Я имею в виду весь цикл: кодирование, отладку и тестирование, рефакторинг, поддержку, документирование. Я мог бы дать критерии качества, если бы был господом Богом, но я не таков :)

> Список ограничений в студию Невозможность использовать оператор (например, составной) как значение параметра макроса/шаблона. Невозможность получать код как результат произвольных вычислений.

> Качество - это производительность труда при разработке в заданной области. Я имею в виду весь цикл: кодирование, отладку и тестирование, рефакторинг, поддержку, документирование.

Ну если так... то хороший язык должен позволять писать программу так, как я считаю нужным (или наилучшим), а не так, как меня заставляет язык. Это позволит ее быстрее читать и рефакторить. Относительно тестирования и документирования проблем почти не вижу (разве что скорость компиляции можно увеличить в 10-100 раз и под вопросом: возможно стоило бы сделать отладчик как в лиспе)

> Я мог бы дать критерии качества, если бы был господом Богом, но я не таков

Ну и как же ты будешь двигаться к языку мечты без критериев качества?

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

Ключевое слово здесь - "я". Единица-ноль, единица-вздор, как сказал поэт. Код должен быть понятен сообществу. Например, в лиспе можно писать как угодно, но я не видел нормальных средств анализа программ на лиспе, не завязанных на особенности реализации. Вроде бы, "код=данные", но на самом деле, в Яве код скорее можно считать данными. Существует чёткая, простая, однозначная и доступная в виде готовых инструментов процедура разбора исходного кода проекта на Яве и в этом отношении она превосходит и лисп, и С++. Есть здесь некий компромисс - чем богаче сам язык, тем сложнее анализировать программы на нём. Конечно, я не сторонник какой-то одной точки на шкале этого компромисса, но если Ява находится на одном конце шкалы, то лисп и С++ находятся _под_ шкалой.

Да и чёто я уже подрастерял пафос на тему языка мечты. Судя по другим языкам, становление языка, писанного в одно лицо, занимает порядка года-полутора. И для этого нужны хорошие времена. Сейчас - плохие времена, нужно заниматься тем, что непосредственно способствует выживанию. Я сейчас работаю полный день и концентрируюсь просто на исполнении служебных обязанностей.

Что я вижу более-менее реальным - это частично обратимый макропроцессор (с парсером-линзой) на базе fuse или, может быть, даже на базе плагинов к средам разработки.
Идея эта - вполне новаторская, при этом она легче в реализации и она гораздо более широко применима, чем язык мечты. Например, мне не хватает макросов для Delphi и для SQL и я вижу вполне реальную возможность накрутить их. Но это уже офтопик :)

> Да и чёто я уже подрастерял пафос на тему языка мечты. Судя по другим языкам, становление языка, писанного в одно лицо, занимает порядка года-полутора. И для этого нужны хорошие времена.

Я тебя не призываю реализовывать язык, а призываю сформулировать хотя бы эскизно что от него требуется. Уклон именно в твое личное понимание я приветствую.

> Ключевое слово здесь - "я".

Да. Мы посовещались, и я решил. (пока кто-то не сделает язык, который меня полностью устроит) я буду его обдумывать и обсуждать, а потом возможно и реализую.

Да я уж вроде писал про "язык мечты". С тех пор ничего не изменилось. Вот здесь: http://www.linux.org.ru/view-message.jsp?msgid=3461466&page=2#3466833

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

>> Как язык - да. Как платформа - сомнительно. FFI не стандартизован. Есть ограничения на работу с FFI в многонитевом режиме (и сама многонитевость тоже не стандартизована).

Правильно, не стандартизован. В С99 тоже не стандартизована многопоточность и по большому счету каждая реализация предлагает свой вариант. К этому быстро привыкаешь... По большому счету, если у языка есть стандарт, то в нем много чего нет - это верно для многихх языков со стандартами. Рюшечки привинчиваются сторонними библиотеками/платформами/имплементациями/итд. С другой стороны Питон или Жава могут себе позволить спецификации, которые сами себе и придумывают.

>> Дельфи меня не настолько разочаровал. Хотя я пользуюсь и лиспом для задач кодогенерации и я не пытался переделывать на Дельфи те задачи, которые я делаю на лиспе. Так что я не могу сравнить.

Дельфи = Windows и этим все сказано. Почему тогда аргументы против лиспа, которые ты привел ранее (в частности отсутствие труъ-кроссплатформенных OSS-лиспов) вдруг стали не верны для Дельфи?

Например ты возмущался на тему, что под windows можно нормально (например без потери многопоточности) пользоваться только коммерческими лиспами, а использование коммерческого дельфи тебя ничем не смущает, странно, да? И тебя не смущает, что OSS вариантов дельфи нет (равноценных по функционалу). Где логика?

Практикой показала, начинать ИЗУЧЕНИЕ ЯП лучше с Паскале-подобных. ИМХО Modula-2, Oberon-2, Component Pascal

Но, хороших бесплатных компиляторов нет.

Кулл!! Программа на языке Brainfuck, печатающая «Hello World!»:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++ .>+.+++++++..+++.>++.<<+++++++++++++++.>.+++. ------.--------.>+.>.

)))!!!!+1

В 2004-м отсканил для истории :) http://airbase.ru/computers/pmk/progs/PMK.djvu +1 с этим тоже дело имел в школе...) хорошая вещь!

http://robos.org/electronics/bfcomp/ почитай.. есть исходный код!

> Дельфи = Windows и этим все сказано. Почему тогда аргументы против
> лиспа, которые ты привел ранее (в частности отсутствие
> труъ-кроссплатформенных OSS-лиспов) вдруг стали не верны для Дельфи?
А я не говорил, что Дельфи идеален. Я сказал, что я в нём не так разочарован, как в лиспе. В общем, я выхожу из этой дискуссии за отсутствием у меня ресурсов для неё. Благодарю за внимание :)

> А я не говорил, что Дельфи идеален. Я сказал, что я в нём не так разочарован, как в лиспе.

Вы на дельфи не писали, что ли?

C/C++ -> Java -> Groovy, но ни в коем случае не наоборот, иначе плюсы осваивать будет нереально сложно.