LINUX.ORG.RU

Lisp & C ф-ции


0

0

Что лучше использовать для выаимодействия C ф-ций (прог) и Lisp:
cffi или run-program и stream ? Т.е. или каждую С ф-цию юзать с cffi, 
или сделать законченную прогу и её уже через run-program ?
Критерии лучшести (ИМХО):
1. С точки зрения Lisp-идеологии ?
2. Скорость. Тут, наверное, скорость - запуск, передача параметров,
       возврат значения, т.е. взаимодействие C<->Lisp.
Ну и другие ?
anonymous
Ответ на: комментарий от Zubok

> Недетерминированность по времени? Появление в процессе работы сборки мусора?

Нет. Если еще и _это_ является проблемой, то я бы его уволил без выходного пособия.

> ИМХО, был бы очень интересный экспириенс.

Ничего интересного, поверь мне. Делаем на Питоне - работает. Даже скучно :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Ничего интересного, поверь мне. Делаем на Питоне - работает. Даже скучно :)

Ах, а я думал, какие-то технические преграды. А ты просто флейм разжечь хочешь на базе Python vs. Lisp :) Все понятно. :)

Тем не менее, ну прикинь, если надо обмен с разными устройствами делать, скажем, по USB. Или с со звуком. И нужно писать на Си POSIX-слой, а потом фигачить свой доморощенный интерфейс, к которому еще и биндинги рисовать. Вместо того, чтобы напрямую поток загнать и прочесть, и поуправлять девайсом. Для этого и сделали POSIX-биндинг. Не вижу пока ничего плохого в таком решении. Хуже будет,е сли мне для работы программы надо будет собирать какую-то libsound4lisp.so, libusb4lisp.so, libcomport4lisp.so и т. д.

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

> ты просто флейм разжечь хочешь на базе Python vs. Lisp :)

Нет, я уже понял, что <joke> вас, твердолобых фанатов Лиспа, проще и выгоднее убить, чем убедить </joke>. В данном случае меня интересует, что будет с программой после того, как написавшее ее дарование уволиться.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Нет, я уже понял, что вас, твердолобых фанатов Лиспа, проще и
выгоднее убить, чем убедить

Нет, я уже понял, что вас, твердолобых фанатов Питона, проще и
выгоднее убить, чем убедить

Товарищ, можно аргументы. Я просо выбираю. Мне надо...

anonymous
()
Ответ на: комментарий от anonymous

> Товарищ, можно аргументы. Я просо выбираю. Мне надо...

Ты выбираешь что? Для чего? Между чем и чем? Про FFI и процессы тебе здесь квалифицированно объяснили. Задавай четкие вопросы, и тебе ответит.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Недетерминированность по времени? Появление в процессе работы сборки мусора?

>Нет. Если еще и _это_ является проблемой, то я бы его уволил без выходного пособия.

Насколько я помню, в разных реализациях есть возможность приостановить GC во время исполнения куска кода. В SBCL это, например, макра (without-gcing ...).

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

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

Семантика этого не очень определена, да (лично мне) это и не кажется достаточным. Может, когда родят наконец realtime garbage collector :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Впрочем, для любителей системно программировать на Лиспе есть BitC :D

Ну биндинг в *libc -- это уже не знаю, как определить. Дальше идет биндинг непосредственно к ядру. Ну а следующий уровень гиканутости -- это ОС на CL. :) Впрочем, и такая есть. Называется Movitz. Операционная система полностью написанная на Common Lisp. Вплоть до драйверов. Там и VGA-драйвер, клавиатура, мышки и пр. Но этот Movitz больше иллюстрация, нежели проект с будующим. Вот драйверочки:

http://common-lisp.net/cgi-bin/viewcvs.cgi/movitz/losp/x86-pc/?root=movitz

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

>> Впрочем, для любителей системно программировать на Лиспе есть BitC :D

> Ну биндинг в *libc -- это уже не знаю, как определить.

O_O

BitC - это отдельный язык системного программирования. основан на Scheme. Никаких биндингов к libc.

Movitz - мервый плод больного сознания.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ну биндинг в *libc -- это уже не знаю, как определить.

Эта фраза относилась не к bitC. Незачем такие O_O круглые глаза делать :)

Zubok ★★★★★
()
Ответ на: комментарий от Zubok

У tailgunner месячные? Грамотному разработчику не составит проблемы разобраться в коде на Lisp, а если это проблема - то нах такого разработчика. Кроме этого есть _принципиальный_ возражения против Lisp?

krum
()
Ответ на: комментарий от krum

> У tailgunner месячные?

Слова не мальчика, но мужа.

Если тебе от этого легче - можешь считать, что месячные. Или климакс. В общем, как скажешь.

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

Ути-пути... эмигрировал в страну эльфов, да?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>Movitz - мервый плод больного сознания.

С этим спорить не буду. Но раз кому-то интересно поиграться, то пускай будет.

Zubok ★★★★★
()
Ответ на: комментарий от krum

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

У разных языков разный уровень вхождения.

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

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

Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

А дальше возникает естественный вопрос: неужели CL настолько лучше Python, что имеет смысл терять месяцы в надежде, что потом догоним и перегоним? Как-то сомнительно.

execve
()
Ответ на: комментарий от execve

> У разных языков разный уровень вхождения.

"У разных людей" этот порог различается на много больше. Может с этого начнём?

> Какие-то (Python) в силу простоты можно выучить относительно быстро и сразу же начать кодировать. И в процессе разработки не приходится прилагать титанических усилий.

Ха-ха. Или выучите Питон _со всеми_ идущими в поставке библиотечными функциями, или выкиньте из CL все аналогичные функции и сравните языки.

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

Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

> Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

Личное мнение, или стат. данные? Описание условий проведения эксперимента и его результаты?

> А дальше возникает естественный вопрос: неужели CL настолько лучше Python, что имеет смысл терять месяцы в надежде, что потом догоним и перегоним?

А по мне - абсурд, а не "естественный вопрос" (и это мягко сказано).

yyk ★★★★★
()
Ответ на: комментарий от yyk

> "У разных людей" этот порог различается на много больше. Может с этого начнём?

В ход пошло креативное цитирование? Изначально речь шла про абстрактного "грамотного разработчика".

> Ха-ха. Или выучите Питон _со всеми_ идущими в поставке библиотечными функциями, или выкиньте из CL все аналогичные функции и сравните языки.

Ха-ха. Про библиотеки мы ещё даже не начинали. Пока что речь шла про язык.

> Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

Бред.

>> Так что лучше говорить не в абсолютных, а в относительных величинах: для Python "не составит труда" исчисляется в неделях, для CL - в месяцах.

> Личное мнение, или стат. данные?

Стат данные.

> Описание условий проведения эксперимента и его результаты?

И список публикаций с индексом цитирования.

> А по мне - абсурд, а не "естественный вопрос" (и это мягко сказано).

У тебя с логикой проблемы.

execve
()
Ответ на: комментарий от execve

> Изначально речь шла про абстрактного "грамотного разработчика".

А если этого абстрактного разработчика учили в MIT схеме?

> Ха-ха. Про библиотеки мы ещё даже не начинали. Пока что речь шла про язык.

Если из CL убрать то, что относится к библиотечным функциям, но не выделено из стандарта - останутся слёзы.

> > Только _непривычный синтаксис_ играет заметную роль (для тех, для кого играет :). Всё остальное - его следствия или полная чепуха.

> Бред.

О какой парадигме из поддерживаемых лиспом ты говорил?

> И список публикаций с индексом цитирования.

Урл?

> У тебя с логикой проблемы.

Нет, это у тебя с основаниями для подобных выводов проблемы.

yyk ★★★★★
()
Ответ на: комментарий от yyk

>> Изначально речь шла про абстрактного "грамотного разработчика".

>А если этого абстрактного разработчика учили в MIT схеме?

"Вы не в Чикаго, моя дорогая" (c)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> "Вы не в Чикаго, моя дорогая" (c)

Конечно, оценивать пригодность определённого языка для неопределённой задачи по его распространённости - это верх логики!

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Конечно, оценивать пригодность определённого языка для неопределённой задачи по его распространённости - это верх логики!

Дружище, это она у тебя неопределенная. У меня она проста и понятна - прогер должен выдавать тексты, которые другие могут понять без лишних усилий. Подчеркиваю красным - без _лиших_ усилий. И в текущих условиях Лисп это не обеспечивает (execve это доходчиво объяснил). Конечно, если бы дело было в окрестностях MIT, или у нас Лисп использовался для обучения - было бы по-другому. Но жизнь такова, какова она есть.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Это ты о своей задаче. Аноним говорил об "управлении устройством" - это определённая зачача?

А о твоей задаче: я правильно понял, что единственный критерий выбора инструмента - его распространённость без учёта его специфики?

И execve ничего не объяснил. Причины нераспространённости лиспа мне самому прекрасно известны. И я соглашусь, что в фабриках по выпуску monkey-кода, в которых собственно инструментарием не занимаются напрочь, в данный момент лиспу делать нечего. А всё остальное - вздор.

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Аноним говорил об "управлении устройством" - это определённая зачача?

Нет. И я не говорил, что Лисп непригоден для этого.

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

Нет.

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

Ты смешал всё в кучу. Возражать этой куче - бессмысленно.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> > Аноним говорил об "управлении устройством" - это определённая зачача?

> Нет. И я не говорил, что Лисп непригоден для этого.

Но ты говорил, что наказывал бы за его использование:

"За написание программы управления устройством на Лиспе я бы как минимум лишил премии."

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

> Нет.

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

> Ты смешал всё в кучу. Возражать этой куче - бессмысленно.

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

>> Нет. И я не говорил, что Лисп непригоден для этого.

>Но ты говорил, что наказывал бы за его использование:

Говорил. И даже объяснял, почему.

> язык, не проходящий по критерию "распространённости", отсеивается автоматически без дальнейшей оценки его пригодности для требуемой задачи?

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

> Я пытался определить границы применимости ваших же утверждений

Растянув их в бесконечность?

> без них ваши слова более чем на бред не тянут.

Ты не обязан отвечать на мой бред

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Вот видишь, ещё одно ограничение твоих утверждений всплывает ;) - "командная работа", причём команда, мягко говоря, "так себе" :)

> > Я пытался определить границы применимости ваших же утверждений

> Растянув их в бесконечность?

Где-то так :) Плоскость легче всего делить прямыми, а прямые - да, уходят в бесконечность :)

> Ты не обязан отвечать на мой бред

Кому не обязан? А вдруг я себе обязан ответить тебе?.. :)

Ладно, можно замять (если хочешь).

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Вот видишь, ещё одно ограничение твоих утверждений всплывает ;) - "командная работа"

Работа всегда командная.

> причём команда, мягко говоря, "так себе" :)

Если мерять качество команды знанием Лиспа - да, конечно. Но оно меряется отнюдь не этим.

>> Ты не обязан отвечать на мой бред

>Кому не обязан? А вдруг я себе обязан ответить тебе?.. :)

Я думал, ты уже всё решил для себя :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Работа всегда командная.

Ну так не интересно. "Квантор всеобщности" или опять таки ограничения в значениях "по умолчанию"?

> Если мерять качество команды знанием Лиспа - да, конечно. Но оно меряется отнюдь не этим.

Нет - качество и в способности быстро освоить наиболее подходящий инструмент тоже.

> Я думал, ты уже всё решил для себя :)

Угу. Всё решил и умер в сей же миг...

yyk ★★★★★
()
Ответ на: комментарий от yyk

>> Если мерять качество команды знанием Лиспа - да, конечно. Но оно меряется отнюдь не этим.

>Нет - качество и в способности быстро освоить наиболее подходящий инструмент тоже.

Вот именно - _тоже_ (т.е. это _один из_ критериев). Но только пока что никто не доказал, что гораздо более простой (например!) Питон является менее подходящим инструментом.

> Всё решил и умер в сей же миг...

Всё решил и начал проводить решения в жизнь. Или я говорю с потусторонним миром? o_O

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Вот именно - _тоже_ (т.е. это _один из_ критериев). Но только пока что никто не доказал, что гораздо более простой (например!) Питон является менее подходящим инструментом.

Ну, именно с питона я и "скатился" на лисп :) Сравнение простоты питона и лиспа слишком субъективно и зависит в тои числе и от таких "нетехнических" факторов, как "си/паскале-подобный синтаксис питона", который более удобен тем, кто начинал с подобных языков, и кому легче извращаться со знакомым языком, нежели использовать наиболее подходящий.

И каждый сам себе должен доказать, что он использует наиболее подходящий в его условиях инструмент. А высказывать "абсолютные истины" "X лучше Y и ниипёт" - удел <вставить наиболее подходящее определение>.

> Всё решил и начал проводить решения в жизнь. Или я говорю с потусторонним миром? o_O

Да ну нафиг - вы меня с кем-то путаете. 1) напоролся на проблему - 2) проанализировал - 3) принял решение (возможно ошибся) - 4) попытался решить - 5) получил результат (х.з. какой) - 6) сделал выводы - см. п. 1. :)

Я к тому, что "всё решил" для меня в первую очередь означает "всё", а это - конец :)

yyk ★★★★★
()
Ответ на: комментарий от tailgunner

> Конечно, если бы дело было в окрестностях MIT, или у нас Лисп использовался для обучения - было бы по-другому.

У вас - это где? В пределах МКАД или даже Садового кольца?

mv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.