Ceramic — кросплатформенный GUI на Common Lisp

А в нем нет скобочек?

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

Скобки видел? Вот они и есть ошибка дизайна. Динамическая типизация и макросы только добавляют говна в котел.

Скобки и макросы - это настолько могучая особенность Лиспа, что средним умам с «косыми» глазами этого ещё очень долго не понять. Динамическая же типизация рулит тем, что не выкручивает «прямые» руки. Те, у кого руки «кривые», а глаза «косые», кто не может обходиться с динамической типизацией не смогут писать не только на Лиспе, но и даже на Си. :-)

Столько ненужно в одном месте, надо же.

PAW - фреймворк, который использовал CERNlib. Удивительно? То же и с GEANT 3.

Это клёво что лисп такой клёвый. Хоть что-нибудь для физики высоких энергий или элементарных частиц на нём написано?

http://www.reduce-algebra.com/bibliography.htm

[Baranov:07] S. P. Baranov. Associated y+b+b production at the Fermilab Tevatron and CERN LHC. Physical Review D (Particles and Fields) 74 no. 7, page 074002, November 2006. [Baranov:06] S. P. Baranov. Topics in associated j/ψ + c + c production at modern colliders. Physical Review D (Particles and Fields) 73 no. 7, page 074021, 2006. [Baranov:08] S. P. Baranov and A. Szczurek. Inclusive production of j/ψ meson in proton-proton collisions at bnl rhic. Physical Review D (Particles and Fields) 77 no. 5, page 054016, 2008.

Нативный код и есть в железо.

Выносите наркомана, он порвался.

что средним умам с «косыми» глазами этого ещё очень долго не понять

Ну да, не всем понять мудрость книги Мормона. Надо очень долго молиться и завести не менее пяти жен, только тогда поймешь.

PAW - фреймворк, который использовал CERNlib.

Нет, это именно что часть поставки CERNlib.

То же и с GEANT 3.

И он тоже часть CERNlib.

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

На нем ведь нет нихрена ,зато он интересный ,да классный

Есть, но реально качественного софта на нём мало. Да и откуда этот софт появится в большем количестве, чтобы ты удивился, если коммьюнити с гульгин нос? :-)

Зато он удовлетворяет критериям «не говна» Анонимуса.

CERNlib - это CERNlib. Она устанавливается отдельно. Она идёт без PAW и GEANT 3, которые ты устанавливаешь потом, если они тебе нужны. Если у тебя было иначе - это проблемы твоей сборки софта/дистрибутива

http://journals.aps.org/prd/abstract/10.1103/PhysRevD.73.074021 http://journals.aps.org/prd/abstract/10.1103/PhysRevD.74.074002 http://journals.aps.org/prd/abstract/10.1103/PhysRevD.77.054016

Ну а cl где?

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

«The calculation of traces is performed using the algebraic manipulation system REDUCE »

Ясно.

А в нем нет скобочек?

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

Я что-то не понимаю. Ты не любишь C++ и QuickLisp, но любишь Common Lisp или что? Какой именно реализации Lisp'а ты симпатизируешь, мой смайлофажный анонимус?

Зачем ты забрела в Lisp-тред, няша? Не видишь что ли, что серьёзные дяди тут С и C++ обсуждают.

commonqt есть и qtools активно пилится.

Они базируются на Qt или просто так названы? Я не в том смысле. В чём проблема взять Lisp для рисования GUI так, как это делает GTK+ или сам Qt, не привязываясь собственно к GTK+/Qt? То есть возможно ли создание на Lisp GUI-фреймворка, который рисует контроллы сам, не опираясь на уже существующие библиотеки?

commonqt есть и qtools активно пилится.

Они базируются на Qt или просто так названы?

CommonQt -биндинг. Qtools - лиспофицированя обертка к нему.

То есть возможно ли создание на Lisp GUI-фреймворка, который рисует контроллы сам, не опираясь на уже существующие библиотеки?

CLIM, Garnet, 10-ки X-овых либ на базе CLX и несколько на основе OpenGL делают/ли так. Проблемы тут две. Во-первых, народ хочет чтобы наш GUI вписывался в текущее окружение, которое на GTK/Qt. Зайди в любую тему c упоминием FLTK/Tk и удивись завалам из кирпичей - гранаты форма кнопок не той системы :( Во-вторых, переносимость. Если X-ы еще, народ c применением CLX как-то осиливает. То вот на win32api почти гарантировано ложит болт.

Ну и на практике лисперов имеющих опыт работы с С/C++ G&Q-интерфейсами больше чем желающих изучать что-то другое и выбирают более знакомое..

полез разбираться в языке и его особеннотях, что бы, хоть что-то ответить кроме «Ck0bKи»

:)

Ты не любишь C++ и QuickLisp, но любишь Common Lisp или что?

Common Lisp - могучий язык, далеко не идеальный, но очень могучий, хотя и старый. QuickLisp, который уже более 5-ти лет почему-то beta, - всего лишь хорошая программа на Common Lisp, цель которой мне понятна, и, вполне благородна - сделать Лисп более доступным для новичков. Я не разделяю «библиотечный» подход везде и всюду, который уводит в сторону от самой важной изюминки Лиспа - возможности создания новых, специфических языков поверх его. В языках типа C библиотеки являются единственной возможностью организации повторного использования, а в Лиспе - нет.

Какой именно реализации Lisp'а ты симпатизируешь

Нет такой реализации. :-)

Нет такой реализации. :-)

Хотя бы реальные проекты пишешь на лишпе? Или только хвалишь? А то ведь как-то на троллинг похоже. Цепепешники аж стулья пачками прожигают.

Хотя бы реальные проекты пишешь на лишпе? Или только хвалишь?

А что ты понимаешь под «реальными» проектами? Протопит - это реальный проект? Для кого-то прототип - это прототип, а для кого-то - реальный проект :-) В реале же одним только Лиспом обойтись нереально. Ну, если только реальность не виртуальная :-)

А то ведь как-то на троллинг похоже. Цепепешники аж стулья пачками прожигают.

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

Я не разделяю «библиотечный» подход везде и всюду, который уводит в сторону от самой важной изюминки Лиспа - возможности создания новых, специфических языков поверх его. В языках типа C библиотеки являются единственной возможностью организации повторного использования, а в Лиспе - нет.

Это всё здорово и замечательно, но это лишь одна из возможностей языка. Очень хорошая возможность, качественно отличающая lisp от других языков, но не самоцель. Иногда проще взять готовую библиотеку (тот же hunchentoot или cl-closure переизобретать смысла нет, ИМХО).

Иногда проще взять готовую библиотеку (тот же hunchentoot или cl-closure переизобретать смысла нет, ИМХО).

А теперь скажи честно и откровенно (самому себе, прежде всего). Если б не было Hunchentoot, cl-closure, стал бы ты использовать Common Lisp для сайтов?

Ну раз пошла речь про C++ и Lisp, не могу не оставить эту ссылочку: https://ru.wikipedia.org/wiki/InteLib Лисп на/в крестах. От Столярова. Это конечно академическая штука, да и обновляется, скажем, нечасто...

Я не разделяю «библиотечный» подход везде и всюду, который уводит в сторону от самой важной изюминки Лиспа - возможности создания новых, специфических языков поверх его. В языках типа C библиотеки являются единственной возможностью организации повторного использования, а в Лиспе - нет.

А как это ты связываешь создание DSL'ей и организацию повторого использования кода? По-моему совсем не связанные вещи.

Насколько я знаю интергация плюсов и общелиспа сейчас очень круто запиливается в Clasp - современной, полноценной реализации CL на плюсах.

Та шо там то жалкое поделие. Вот человек скрестил «ежа» и «ужа» - https://github.com/drmeister/clasp. :-)

А что ты понимаешь под «реальными» проектами?

== полезные кому-нибудь, которые используются.

А как это ты связываешь создание DSL'ей и организацию повторого использования кода? По-моему совсем не связанные вещи.

Что в программированиие может быть более пригодным для повторного использования, нежели чем язык программирования? Суть повторного использования в отделении общего от частного. Создав свой язык, на котором потом пишется прикладная задача, можно приспособить этот спец. язык для написания аналогичных задач. Пола Грэма почитай ещё раз. :-)

А как это ты связываешь создание DSL'ей и организацию повторого использования кода?

Сравни «регулярку» и аналогичный по результату алгоритм на строковых функциях. Если в принципе не знать о существовании регулярных выражений, то можно аккуратно упаковать этот алгоритм в библотеку, выложить в репу, инкрементировать счетчие библиотек .. и повторить цикл заново еще раз 10 для других частных случаев. А можно просто научится пользоваться регулярками. Это все максимально упрощеный пример призваный показать что есть основополагающие вещи которые в том числе с помощью dsl покрывают целые области и есть просто библиотеки рожденые скорее незнанем и не прорабоностью каких-то фундаментальных вещей.

Возращась к протоколам, можно было представить достаточно емкий dsl. Который давал бы возможность уместить описание протокода на одной странице, давая возможеность сразу понять принципы его работы. А то на практике народ умеет делать http-запрсы с помощью библиотеки. Но не догадывается о нужности передачи и вобще о наличии Referer-а.

Может ты еще и ребол знаешь?)

Ограничено. Вижу в нем мало смысла при наличии лиспа.

Но ведь там гораздо упор на DSL'и, гораздо больше, во всяком случае из того что видно в стандартной либе. Хотя parse можно и в лиспе реализовать. Надо попробовать.

Но ведь там ...

Смысла не вижу потому что маленькая нишевая штука с врожденными тараканами автора. Все остальное на этом фоне представляет лишь теоритический интерес.

По-твоему лучше писать дсли в виде s-выражений? ребол то дает дсл для написаний дслей)

Я о другом говорил. Но приминительно к лиспу, да, лучше скобками. Что бы не созидать на ровном месте dsl для написания dsl-ей, которые в свою очерь чего-то д-эс-элят :)

Я не разделяю «библиотечный» подход везде и всюду, который уводит в сторону от самой важной изюминки Лиспа - возможности создания новых, специфических языков поверх его.

А разве макросы/ДСЛ нельзя в библиотеки повыносить?

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

А разве макросы/ДСЛ нельзя в библиотеки повыносить?

В «библиотеки» в смысле квиклиспа? Да пожалуйста, выноси. Кому они нужны только? :-)

а те которые выстявляются наружу со скобками врятли прокатят.

Зачем их выставлять «наружу»? Зачем писать на Лиспе в «библиотечном» стиле для «наружу»? Лучше бы над реализациями работали. Пользы было бы больше, чем от сотен ненужных какашек :-)

а те которые выстявляются наружу со скобками врятли прокатят.

Конечно же, такие вещи, как cl-pprce, как Postmodern, как Parenscript и т.п. очень даже годятся для QuickLisp. И есть смысл работать над ним совместно всему сообществу. :-)

а те которые выстявляются наружу со скобками врятли прокатя

Мне вот интересно, ты когда это писал, о каком именно dsl думал?
А чисто практически попробуй вспомнить когда с http работаешь, заголовки вручную построчно пишешь или как? То бишь не надо смешивать и взбалтывать транспортный уровень. Его беречь и отделять. И в роли КО отмечу, что поправить принтер/ридер для работы без скобок задача банальная.

лисп? да вы смеетесь? )

Кложуру взять и не греть голову.

Кложуру взять и не греть голову.

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