Ясно, про семантику языка только не очень понятно в контексте CL

Способствует простоте кодогенерации или, наоборот, анализу при написании компиляторов :-) Тот же цепепе, например, слишком контекстно-зависим, поэтому создание парсера или компилятора для него, как уже было сказано, заслуживает медали на грудь :-) И на CL тоже пишу :-) Хотя бесплатные реализации мне не нравятся, а платные - очень-очень дорогие :-) Lispbox - это по большому счёту просто упакованные SLIME с Emacs :-) Никогда даже и не трогал его, ибо поставить SLIME легко и просто :-)

я как раз сейчас занимаюсь поиском ЯП для OS-проекта

Это будет игрушечная ОС симулякр/рантайм, или же ОС для bare metal? :-)

Off-topic
Вот-вот. Теперь и ты понимаешь мою проблему. За что меня сразу и не взлюбили тут. Сейчас в моем списке:

• не явно выражаюсь иногда. Под матаном подразумеваю математику в общем и целом (хотя, в принципе, во всех моих сообщениях видно что когда я имею ввиду математический анализ, я так и пишу - мат. анализ, и не иначе, но тем не менее меня все равно за это шпыняют, видать в православных недоВУЗах привыкли говорить матан, я вот лично в русском языке не знаю такого слова (разве что на Луркморье), поэтому считаю, что по праву забрал его себя для замены на другое значение (общее значение математики в целом), просто иногда «математика» лень писать)
• говорю о некоторых вещах слишком поверхностно (что дает некоторым товарищам возможность вырывать мои фразы из контекста, и цитировать во вред мне)

Вот и ты добавил новый «баг» в мою коллекцию. Я не явно использую сокращения. Когда я говорю OS-проект, (да я понимаю, что OS в общем случае это operating systems, но блин - неужели из моего контекста так сложно меня понять, я ведь не думаю что ты скажешь - Operating System-проект, даже звучит глуповато) я подразумеваю OpenSource-проект.

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

Если очень хочется - да, можно.

И чем такие интерфейсы отличаются от обычных классов (со множественным наследованием)?

По поводу ListBox, вот единственное что отталкивает, дак это

https://common-lisp.net/project/lispbox/
Last updated: February 6, 2011

Никогда даже и не трогал его, ибо поставить SLIME легко и просто :-)

Да, SLIME обязательно гляну, только вот жалко что под vim мало плагинов я нашел в инете для CL. Придется все-таки emacs осваивать.

Когда имел место быть тот разговор я ещё пешком под столом гулял

Тю, смайлик, так ты тоже школота оказывается. Понарожали дебилов...

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

Да, речь про «CL для математики».

Ладно не буду спорить, просто скажу что уже объяснил это выше, когда на меня накинулись.
Я сказал что разговаривал со смайликом в контексте lisp-по подобных, и сравнивал с Java (о чем кстати тоже написал в том же комменте), и всего лишь высказал мнение, что lisp-по подобные, по сравнению с Java куда как лучше подойдут для мейнстрима математических расчетов, а Java для мэйнстрима в «ынтырпрайз». Вот и все. Если проследить ветку нашего общения со смайликом, то это почему-то сразу бросается в глаза. Но другие посчитали, почему-то, что я своей фразой

Я ничего и не сказал про fortran, но вот ни C, ни C++ тут точно не в тему.

дискредитировал их православные C/C++, и совсем не хотели воспринимать мои слова в том контексте, в котором они были сказаны изначально.
То же самое вышло и со всеми остальные фразами, типа

Лисп изначально отталкивается от математических моделей

где я имел ввиду что lisp изначально создавался Маккарти для моделирования и изучения проблем AI, что уже само по себе является явным преимуществом для построения каких-бы то ни было мат. моделей. (опять же, по сравнению с Java, и я все время говорил с контексте lisp-по подобных, это уже позже мы перешли на конкретных CL).
Ну вообщем и т.д. и т.п. Я уже отнес это в разряд «багов» под номеров два.

Тю, смайлик, так ты тоже школота оказывается. Понарожали дебилов...

Ну уж за старшими в этом плане не угнаться :-) Понапросрали всё, что только можно и даже то, что никак было нельзя :-)

Вот-вот. Теперь и ты понимаешь мою проблему. За что меня сразу и не взлюбили тут.

А может быть, твоя проблема в том, что слишком много внимания обращаешь на завистливых ремесленников? :-)

Когда я говорю OS-проект, (да я понимаю, что OS в общем случае это operating systems, но блин - неужели из моего контекста так сложно меня понять

Откуда я знаю, может ты хочешь создать Open Source Operating System? :-) Вбей в любой поисковик аббревиатуру «OS» и посмотри КАК поймёт тебя поисковик :-) В этом то и сила однозначной и хорошо проработанной семантики, которая в том же цепепе, так горячо любимом ремесленниками, является полным отстоищем :-) Представляешь, как для такого отстоища трудно компилятор писать? :-)

А может быть, твоя проблема в том, что слишком много внимания обращаешь на завистливых ремесленников? :-)

Вполне возможно, кстати.

Вбей в любой поисковик аббревиатуру «OS» и посмотри КАК поймёт тебя поисковик :-)

Именно поэтому я назвал свой список - списком «багов», а не «фич» :)

Я не знаю, что за проект ты там надумал, но я бы, наверное, обратил на твоём месте внимание на Racket :-) Если есть время, пройди курс HTDP на нём :-) Поднимешь скил, оценишь поверхностно сам язык :-) В отличии от CL, в Racket более тесное сообщество из академ. кругов :-) Сам язык больше, чем CL :-) Активно развивается :-) А CL, скорее всего, застрял и вряд ли кто-то будет пересматривать его стандарт :-)

Спасибо, обязательно гляну как время освободится.

Проект с математическим уклоном. Может быть знаешь TeX? Вот если простыми словами - я хочу написать библиотеку для расчета основных формул. И желательно именно на функциональном языке. Для начала сделать расчеты для самых элементарных формул, и постепенно добавлять новые.

Racket возьми :-)

Да, проглядел на скорую руку, убедил :) А еще подкупила дата последней версии 6.3 (23 ноября 2015). Решил пока остановиться на Racket и Haskell, сейчас месяц их поизучаю, заодно сделаю вывод для себя, действительно ли такая огромная разница между мультипарадигмой и чистым функционалом как многие говорят. А то из статей особо и непонятно ничего.

И чем такие интерфейсы отличаются от обычных классов (со множественным наследованием)?

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

Добавление фич -> усложнение языка ->
1) усложнение компилятора -> больше возможностей для багов в компиляторе
2) растёт сложность изучения -> падает квалификация программистов -> падает качество кода
3) резко возрастает сложность отладки

Несмотря на то, что golang намного проще Haskell'а, компилятор (включая все сопутствующие библиотеки) у него примерно такого же размера.

~/devel/hs/ghc> cloc .                                                  
   17320 text files.
   16113 unique files.                                          
    7326 files ignored.

https://github.com/AlDanial/cloc v 1.66  T=50.64 s (202.7 files/s, 25671.7 lines/s)
---------------------------------------------------------------------------------------
Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
Haskell                               8789         171253         216023         650312
C                                      274          11284          13646          60363
Bourne Shell                            94           3545           4218          28070
HTML                                   160            438             51          26858
C/C++ Header                           267           4801           6623          14631
Java                                    60           2668           9512          14191
yacc                                    10           1941             10           9060
make                                   425           1736           1299           6957
Racket                                  34            314            269           4459
m4                                      17            584            219           3935
Fortran 77                               6            662           1049           3527
MATLAB                                   4            228              0           3405
Standard ML                              1            174            128           3004
XML                                      2            321              2           2196
Pascal                                   1            548            395           2101
Python                                  14            696           1190           1843
CSS                                      9            417             80           1786
Lisp                                    24            100             88           1722
YAML                                    28            146            113            976
Objective C                             12            127              3            606
Assembly                                 7             52            105            475
Prolog                                   3            159            132            473
Perl                                     6             83             35            448
JavaScript                               2             56             13            302
C++                                      6             66              2            288
Bourne Again Shell                       3             23             53             67
D                                        2             16             39             59
Windows Module Definition                3             19              0             58
Objective C++                            1             11              3             21
C Shell                                  2              6              0             20
Windows Resource File                    1              0              0              1
---------------------------------------------------------------------------------------
SUM:                                 10267         202474         255300         842214
---------------------------------------------------------------------------------------

~/src/go> cloc .
    4975 text files.
    4864 unique files.                                          
     404 files ignored.

https://github.com/AlDanial/cloc v 1.66  T=24.79 s (184.6 files/s, 41513.7 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
Go                                4027          94160         114664         703466
Assembly                           330           6036          15336          40713
HTML                                41           4923            198          33301
C                                   83           1063            930           7258
Perl                                12            184            177           1132
Bourne Again Shell                  25            210            268            958
XML                                  4             85              9            623
Bourne Shell                         8             71            302            467
Python                               1            121             88            295
DOS Batch                            5             55              1            235
JavaScript                           4             48            122            231
C/C++ Header                        15             50            144            210
CSS                                  3             51              9            176
yacc                                 1             27             20            155
Protocol Buffers                     1              1              0            145
Windows Resource File                4             25              0            116
make                                 8             14             10             48
JSON                                 2              0              0             36
awk                                  1              1              6              7
C++                                  1              3              5              7
-----------------------------------------------------------------------------------
SUM:                              4576         107128         132289         789579
-----------------------------------------------------------------------------------

Вопрос в топике не о нужности ООП или отдельных его фич, а в каком языке ООП лучше. Де-факто, ООП лучше в С++, ибо есть аж 2 варианта множественного наследования. В то время, как Java не имеет никаких заметных преимуществ в ООП перед С++, кроме, разве что, единой иерархии классов.

Лучше - практичнее. А даже в самом С++ не то что наследование боятся (IoC в С++), а за множественное вообще руки рубят. В Java интерфейсное множественно наследование поощряется и обычно не имеет runtime стоимости

В Java интерфейсное множественно наследование поощряется и обычно не имеет runtime стоимости

По твоему, в плюсах множественное наследование интерфейсов никто не делает? Пусть интерфейсы там и больше «логическое понятие».

Делает, только в том и дело что даже в плюсах ограничиваются интерфейсами. Как и в Java. Но в Java например нету психологического барьера к этому, так как в рантайме интерфейсы могут вытереть. А в том треде, на который я привел ссылку, там народ как от прокаженного кидается в любом наследовании с виртуальными методами, так как оно вкомпилируется в бинарь раз и навсегда. Реальное множественное наследование - зашквар во всех вменяемых code style.

Так где лучше ООП?

за множественное вообще руки рубят

Слушай больше ландухов и простофиль :-) Множественное наследование абстрактных классов без данных в пределах одной библиотеки в цепепе - это абсолютно нормальная техника :-)

Делает, только в том и дело что даже в плюсах ограничиваются интерфейсами.

В классах экзепшенов применяют множественное наследование нередко.

Привет участникам Специальной Олимпиады!!!

subj

Извиняюсь за офтоп, но:

На всякий случай объясняю правило ЛОРа: ответы на некорректные сообщения тут удаляются вместе с самими н.с.. Часто - со снятием скора. Нередко - с существенным, если флудорекурсия глубокая. И не всегда сразу. Бывает, что никогда, но тут уж как повезёт.

Поэтому если тебе хамят - не плоди мусор и не отвечай в том же стиле. Либо игнорируй, либо пиши в спецтему. В большинстве случаев первого варианта достаточно. Анонимусу всё равно, он неубиваемый, а ты можешь в запущенном случае внезапно огрести бан и потом долго недоумевать, за что.

Удачи.

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

Привет! 😍😘❤️💋

Спасибо, по поводу правил понял, уже получил по -2 с двух веток, но ничего страшного. За все нужно платить, как говорится.
По поводу:

Для квалифицированного сравнения надо бы на каждом из них сделать по практическому проекту несколько сложнее хеллоуворлда.

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

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

Ну тогда успехов с Racket и Haskell. Я вот тоже всё мечтаю Erlang поковырять, но чувствую, так это мечтой и останется, всю жизнь на процедурах и ООП сижу...

Vala.

На вас накинулись потому что хоть что-то хорошее о лиспе написали. Иногда легче унизить/затравить/наехать на человека, чем оспорить его аргумент, вот этим и пользуются.

На вас накинулись потому что хоть что-то хорошее о лиспе написали

Это случай так называемого вранья.

Вы не можете это доказать. А я не могу доказать свое утверждение. Но это хорошо что они оба написаны здесь.

Вы не можете это доказать

Это очевидно любому, кто даст себе труд прочитать тред.

Несмотря на то, что golang намного проще Haskell'а

Ага, 16К файлов против 4.8К это «примерно такого же размера».
При этом в стандартной библиотеке Go есть реализации сетевых протоколов (http, http2, smtp, ...), криптографии (aes, des, sha, md5, ...), форматов картинок(jpeg, png, gif), сериализации (json, xml), архивов (zip, gzip, bzip2, ...), и т.д. и т.п.
И это не биндинги к библиотекам на С как делают в других языках, а полноценные реализации на Go, что гарантирует отсутствие переполнений буферов, рандомных крешей и прочих heartbleed'ов. Так что сравнение по количеству строк кода не отражает реальную картину.

P.S. То что люди не знают что МАТ.АН. это сокращение от МАТематический АНализ, считаю проблемой нашей системы образования.

Так что сравнение по количеству строк кода не отражает реальную картину.

Почему? И почему сравнение количества файлов лучше её отражает?

Так я про это и говорю что ни то ни другое не работает. В стандартной библиотеке Go есть почти все что нужно для эффективной разработки. А у хасекеля считай вообще нет стандартной библиотеки. А сравнение по количеству кода это никак не учитывает.

Off-topic

P.S. То что люди не знают что МАТ.АН. это сокращение от МАТематический АНализ, считаю проблемой нашей системы образования.

О, привет еще одному образованному. Раз ты снова колышешь эту тему, мне не сложно разжевать это еще и для тебя.
Я не сказал что не знаю этого сокращения, я сказал всего лишь, что оно не принято официально, от слова совсем. Разница ощутима? Так только эти ваши уютненькие делают, и малограмотные студенты в недоВУЗах. Оказалось что использование «общепринятого» (в кавычках месье, я ставлю здесь акцент, «шорт побири»!) сокращения не по назначению (строго определенной группы людей) карается закидыванием ссаными тряпками. Видимо больше придраться было не к чему.
Нередко, многие здесь используют какой-то свой, один лишь им известный слэнг, применяют кучи аббревиатур и обозначений в контексте совершенно не подходящем по смыслу, но я, слава Богу, выше того чтобы указывать им на это. А еще тут очень много таких хомячков, которые пытаются поймать вас на незнании русского языка, указывая зачастую на элементарную путаницу и упущения. Ну видно тащат скелеты из собственных шкафов.
Вот цитата из совместной работы Амурского и Волжского, называется «Университетсткие записки», там по сабжу хорошо сказано

Наш лектор по математическому анализу Вячеслав Васильевич Фёдоров очень не любил, как студенты сокращали название его предмета. Видеть слово «МАТАН» на обложках тетрадей с конспектами было выше его сил. Как-то раз, не смотря на всю свою флегматичность, он даже выступил с коротким заявлением перед лекцией о том, что это сокращение неблагозвучно, некрасиво, что лучше уж сокращать как-нибудь по-другому. Например, «Матем. Ан.».

Но не переживайте, такое до ВУЗов не допускают, поэтому вам, конечно же, не обязательно это знать.
Я думаю не стоит утруждать себя приписками на тему «проблем нашей системы образования».
Это между прочим еще один наглядный пример, когда человек не в состоянии прочесть всего треда целиком, и говорит исключительно с позиции одного сообщения. Продолжайте, прошу вас. Я думал сия тема исчерпана, но оказалось я ошибался :)

Продолжайте, прошу вас.

Ну так если ты знаешь что означает конкретное слово, то в чем проблема? Если не нравится то не используй, а если нравится то используй по назначению, зачем изобретать новые смыслы для существующих слов, которые мало кто поймет. А то бывает используют разные слова для красоты, а смысла не знают. А стороннему человеку не отличить или реально не знает или д’Артаньян.

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

Если используют не по смыслу, то обязательно найдется кто-нибудь кто укажет им на это, не беспокойся.
И да, на моих тетрадках было написано «мат. анализ»

Ну так если ты знаешь что означает конкретное слово, то в чем проблема? Если не нравится то не используй, а если нравится то используй по назначению

Хорошо, но давайте рассуждать как здравомыслящие люди. Вы же не можете от меня этого требовать, верно? Это раз.
Второе. Вы не знаете какие конечные цели я преследую. Я могу вам ответственно заявить, что многим людям рвет пукан от того что говоря «матан», можно подразумевать под этим математику. Как бы обобщая. Т.е. математический анализ, это подраздел математики, сл-но, говоря «матан», я могу использовать направление от частного к общему. Да, направление неверное, но можно предположить что это делается намеренно, например, чтобы схватить с кого-нибудь лулзов, ожидая естественно, что меня начнут тыкать в это, но забывая что кенгуру тоже животное :)
Но это только первый вариант развития событий. А есть еще и второй. Когда человек это делает неумышленно. После этого объясняет почему (в удаленных в треде есть мое объяснение), и продолжает ловить тряпки (не переставая вместе с этим ловить лулзы, заметьте, для меня это все видится в позитивном ключе).
То есть понимаете, это как если бы я сейчас начал к вам придираться что вы называете Haskell - «хасекелем», или что словосочетание для вас обозначает «конкретное слово».

Ну так если ты знаешь что означает конкретное слово, то в чем проблема?

Простыми словами - смысл предельно ясен, но придраться не к чему, а хочется (поверьте, здесь есть такие индивидуумы). Вот они и придираются к чему только можно.

P.S. То что люди не знают что МАТ.АН. это сокращение от МАТематический АНализ, считаю проблемой нашей системы образования.

Хм., я всегда думал, что Матанал — это, «Математический анальный секс».

Нет там никакого ООП

Давайте делить ООП в целом на конкретные реализации. Так есть полная реализация ООП по Алану Кею (описана в книге Smalltalk-80, принципы ООП можно найти гуглом), есть «контрактный» подход Бертрана Мейера, функциональный подход (объект по сути - функция высшего порядка) и ... всё остальное.

«ООП» (именно так, в кавычках) в C++ и Java бралась больше с Simula, нежели со Smalltalk. А Simula не является языком, который полностью реализует парадигму ООП, собственно сам термин ввёл А.Кей, а не Кристен Нюгордом или Оле-Йохан Даль. Отсюда возникает некая путаница.

Что есть объект в С++? По сути просто сахар над примитивами Pure C. Как таковых плюсов от использования классов C++ я не видел ни один раз. Поэтому долгое время писал на Pure C используя простые структуры. В первую очередь минус C++ - это экосистема, которая не является объектной (я сейчас не о батарейках типа Qt). Что это значит? В ООП языке всё есть объект, нет возможности прямо изменять переменные (только реакции на «сообщения»). В этом случае программист получает большой профит - он пишет на абстракциях высокого уровня, описывая сами объекты (через классы) и их реакции на взаимодействие. По сути - описывает «состояние системы», которое меняется при взаимодействии.

Подход Java несколько другой... Всё же люди попытались реализовать ООП-парадигму но не до конца. Из этого исходит проблема - часть принципов А.Кея Java соблюдает, а часть - отбросила, решив, что Simula ООП. Парадокс в том, что тот же XOTcl (расширение для Tcl) гораздо более ООП, чем выбранная как ООП-язык Java. Java - классическая императивщика, на подобии C++ (хоть и ближе к ООП, но все же), но не дающая именно ООП-экосистемы, как тот же Smalltalk.

По сути - программисту плевать на то, насколько инструмент «чистый», ему надо решать конечные задачи. А в этом случае удобно иметь «мультипарадигменный язык», который позволяет выдать решение быстро, т.к. имеет много «сахара» (вне зависимости от основной парадигмы) и элементы других парадигм. С одной стороны - это понятно и хорошо. С другой - разработчики таких языков как Java, C#, C++, Python пихают в них всё подряд, не задумываясь над дизайном языка. Они делают швейцарский нож, который по идее может заменить что угодно. Но вот делают такие «универсалы» то, что тебе надо...не так хорошо. Не так давно я писал сложный рекурсивный алгорит на Python3.5 (понадеялся, что «пистон» еще и функционален). Итог - устал бороться с проблемами и скоростью рекурсии в Python и переписал всё на циклы. Код без ФП на python3.5 - 870 строк кода, код на ФП python3.5 - примерно 190 строчек кода. Причем 190 строк - более понятны и логичны, нежели, вроде бы, более человеческая «императивщина». Итог - решение на ФП я накидал за 3 дня, решение императивное - полторы недели. Итого - две недели, из которых реально могло всё закончится через 3 дня. Но язык для ФП не предназначен. Но Python3.5 проще и на нем проще найти нам было программистов. Итог - мы не стали использовать Erlang или Go, т.к. «молодняк» пугался ФП.

Дополнение к прошлому посту

Аналогично и C++/Java/<потомок_Simula> - они дают базисные возможности ООП, которые немного уменьшают код, но реальные «+» ООП, такие как TDD - на них навряд ли можно ощутить. Просто воспринимайте их как «языки-помойки с элементами ООП и ФП», тогда всё будет хорошо.

А вот если хотите по правде понять ООП - почитайте лучше Blue Book of Smalltalk. Там все принципы изложены и показаны как оно должно быть в рамках именно этой парадигмы.

Отличный ООП код пишут даже на ванильном перловом ООП, чего тут спорить?
Кто сильней, боксёр или самбист? Тот кто больше тренируется. Однозначно сосут только пистон и пых, это всё что нужно знать неофиту о программировании

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

+1. Вообще, хороший пост, мне понравился. Только

Итог - мы не стали использовать .... Go, т.к. «молодняк» пугался ФП.

немного рвет шаблон :) Я конечно не знаю близко Go, но не раз слышал мнение, что это самая что ни на есть махровая императивщина для «пугающегося молодняка»

немного рвет шаблон :) Я конечно не знаю близко Go, но не раз слышал мнение, что это самая что ни на есть махровая императивщина для «пугающегося молодняка»

Мы тоже такое читали. Но это не совсем так. В Go много от функциональщины, нет классов и объектов, сложные термины... На практике оно всё просто, но молодняк всё равно пугался. Даж е того минимума, что есть. По сути своей Go - это что-то вроде Python, только функционального более (читай - пригоден для «говнокода» и «велосипедов» молодняка), но даже элементы ФП у российских выпускников вызывают ступор.

Lispbox это тоже самое, что и SLIME+Emacs, только из коробки и древнее. лучше поищи какую-либо portable Emacs + SLIME из репозитория, там вполне несложно настроить.

ещё, попробуй IDE от den73 clcon  — «из коробки» SBCL + Tcl/Tk

по установке SLIME есть даже, блин в контактеге: ссылка

см. также lisp20150507.pdf или тут

«С. П. ГОРЛЯНСКИЙ РЕШЕНИЕ ЗАДАЧ НА ЯЗЫКЕ ПРОГРАММИРОВАНИЯ ЛИСП

Учебно-методическое пособие по дисциплине «Компьютерные технологии и историческая наука» для студентов 5 курса дневной формы обучения и 6 курса заочной формы обу- чения специальностей – 8.030301 – «история» образовательно- квалификационного уровня «магистр» и 7.030301 – «история» образовательно- квалификационного уровня «специалист» профессионального направления подготовки 0203 «Гуманитарные науки» Симферополь »

во оно как, для ИСТОРИКОВ!!!

там первые главы как раз про настройку SLIME, правда, для Lispbox (распакуйте архив, и полетели).

в общем, видос вконтактеге про Emacs + SLIME + SBCL + live coding

не сильно сложнее этого.

Нет там никакого ООП

Все так, но ведь gobject уже куда большее ооп, там хоть сигналы есть, да и get/set уже по сути сообщения, а gobject во многих языках есть, в том числе и в крестах с питоном.

И, кстати, непонятно, зачем они тащат фп в пистон, когда сам же гвидо и все пистоновцы говорят, что это чисто императивный язык и фп лучше в нем не использовать, сейчас давже всякие reduce убрали в отдельный модуль, странно от него ждать какой-то вменяемой поддержки фп, так, для галочки сделали, ибо сейчас фп — что в 90-х ооп, громкая фича.

В Go много от функциональщины

Go — самый не фп язык из всего, что сделали за почледнее время, даже питон и с++ куда больше фп языки, не говоря уже о расте каком-нибудь.