LINUX.ORG.RU

Ручное управление памятью в лиспе

 


2

3

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


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

вот тут в бложике человек давным-давно пишет функциональщину на C++. даже сравнение у него было с Хаскеллем вот вот и вот начало

это ещё даже не С++11.

для сравнения, как эта функциональщина выглядит на D

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

То, что паттерн-матчингом пишется в две строки и понятно даже джуниору, без него превращается в месиво и классов и методов в них.

Не превращается. Ты просто некомпетентен в ООП-языках.

Си не справляется
C++ не справляется
Java тоже не справляется
только LISP справляется.

Оkay. Но почему тогда на лиспе никто не пишет?

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

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

Окей, массовый программист туп и не может освоить лисп.

Но почему сами лисперы ничего не могут написать на лиспе? Где проекты масштаба Linux kernel, OpenOffice, GNOME, KDE, JBoss, Apache? Почему за 50 лет существования лиспа так ничего и не было написано?

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

Что-то не увидел я ничего хорошего там для ФП. Ничем не лучше С++.

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

Почему за 50 лет существования лиспа так ничего
и не было написано?

Ну вот ложь же. Просто большинство старых систем давно вышли из употребления (либо затерялись в глубинах космоса).

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

Просто большинство старых систем давно вышли из употребления

Так почему на лиспе не пишут новые? С учётом его достоинств-то?

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

Потому что в 90-ых железо было слабое, инструменты были не развиты и C++ пихали куда-только можно

Зато теперь железо мощное и поэтому Си++ гонят из всех областей, предпочитая даже голый Си.

1. Common Lisp для интеллектуальных алгоритмов 2. Java для веб 3. C++ для скорости 4. Python для скриптотни вокруг этого

Не готов судить о их умственных способностях только по списку языков.

Вроде правильно все сделали за исключением того, что без Си++ они вполне бы могли обойтись заменив его на Си, тогда бы можно было использовать эти оптимизации и из CL, и из Python, и из Java. Зачем им ещё Питон понадобился тоже нужно посмотреть.

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

а давай ты пойдёш и перечитаеш МакКарти и пляски вокруг IPL

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

ну и про отличие S и M представления и вообще счего оно по началу у МакКарти было.

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

Так почему на лиспе не пишут новые? С учётом его достоинств-то?

Пишут, но лисперов не хватает. Мне на каждой странице надо всё снова повторять?

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

Ты просто некомпетентен в ООП-языках.

Ну так напиши красивый код, который делает паттерн-матчинг классов с агрегированием в ООП-языке.

Но почему тогда на лиспе никто не пишет?

Пишут, но не так много как на Си++. Причин несколько от дебилов которые постоянно про «зиму ИИ» вспоминают и тех кто за скобками леса не видит и до объективных косяков как в CL, так и в Схемах.

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

Зато теперь железо мощное и поэтому Си++ гонят из
всех областей, предпочитая даже голый Си.

Я не вижу логики в этом утверждении. Фабула подразумевает обратное. Впрочем, С++ уже даже в GCC разрешили.

Скажем так, широкое распространение C в open-source связано с моделью разработки, которая основана на использовании широких масс, среди которых встречаются люди самой разной квалификации. Когда открытые проекты пишут ограниченной командой профессионалов (MongoDB или там Sphinx Search), то гораздо чаще выбирают C++.

На самом деле С++ уходит из тех областей, где ему не место (бизнес-логика и т.п.) и наступает на C, как, собственно, изначально и задумывалось.

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

Где проекты масштаба Linux kernel, OpenOffice, GNOME, KDE, JBoss, Apache?

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

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

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

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

ну и почему DOD выбрала Ада&CL и как распределялись роли/задачи

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

Лисп, в смысле CL, это совсем не панацея

Серебрянной пули нет (с) К.О.

и сегодня непонятно зачем он нужен.

Писать программы? К.О.

Интерактивная разработка, CLOS/MOP вообще и мультиметоды из коробки в частности, протокол обработки условий, маросы (при разумном их применении), специальные переменные, какой язык может похвастаться тем же?

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

я лично находил много достаточно большого размера проектов написанных на Лиспе.

Так покажи же их.

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

CLOS/MOP вообще и мультиметоды из коробки в частности, протокол обработки условий, маросы (при разумном их применении), специальные переменные, какой язык может похвастаться тем же?

Но зачем? Ведь всё вышеперечисленное не даёт реальных преимуществ на практике; не согласен — опровергни.

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

Так покажи же их.

Тебе показываешь, а ты снова за своё через несколько постов. Сколько можно?

Но зачем? Ведь всё вышеперечисленное не даёт реальных
преимуществ на практике; не согласен — опровергни.

Ок, только я не буду повторять это снова каждый 10 постов.

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

2. Мультиметоды мечта многих адептов ООП, С++, и Александреску в частности. Профит настолько мощен, что только дебил будет пытаться это опровергнуть.

3. Протокол обработки условий делает обработку ошибок более гибкой и мощной. Не согласен - опровергни.

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

5. Специальные переменные имеют все преимущества глобальных переменных, но лишены их недостатков. Профит очевиден и весьма существеннен. Не согласен - опровергни.

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

Серебрянной пули нет (с) К.О.

Этого капитана кажется зовут Фредерик Брукс ;)

Писать программы? К.О.

Вроде как лисп он лучше всего годится для написания программ, которые пишут программы, нет? Только тут, на мой вкус, он проигрывает математике.

[...много...] какой язык может похвастаться тем же?

Чтоб все в одном месте, видимо никакой. Только оно все вот прям надо всегда?

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

E

Тебе показываешь

Где? Ты смог показать только QPX, но ведь это капля в море. Проектов подобного масштаба на мейнстрим-языках — десятки тысяч. Следовательно, лисп не так мощен, как его рисуют адепты. Ведь если бы он был «на порядки мощнее» мейнстрима, то и проектов можно было бы сделать на порядки больше. Даже при учёте малого количества лисперов. Следовательно, лисп не так мощен, как утверждают адепты. QED

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

Охуенское доказательство, чо. Прямо по понятиям предъявил. Дерзко, чотко. Пацаны не прикопаются!

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

Вроде как лисп он лучше всего годится для написания программ,
которые пишут программы, нет?

Нет. Программы, которые пишут программы, это больше из кинофильма Матрица (как раз один адепт пробегал). На практике просто пишут программы.

Только оно все вот прям надо всегда?

Надо? Настоящие суровые программисты пишут всё на С и считают, что его достаточно.

archimag ★★★
()
Ответ на: E от anonymous

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

В вашем утверждении отсутствует причинно-следственная связь.

если бы он был «на порядки мощнее» мейнстрима

Это исключительно ваши больные фантазии. Я не могу их комментировать.

Охуенское доказательство, чо.

Опровергай. Я почитаю.

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

В вашем утверждении отсутствует причинно-следственная связь.

Разумеется, потому что ты её специально вырезал. Она объяснялась в следующем предложении, которое ты предпочёл «не заметить».

А теперь попробуй прочитать сообщение целиком.

Опровергай. Я почитаю.

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

Опровергай. Я почитаю.

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

А, я забыл, что у тебя проблемы с иронией и иносказанием. Специально для таких поясняю. «Преимущества общепризнанны», «профит настолько мощен, что только дебил будет пытаться это опровергнуть», «профит очевиден и весьма существеннен» — это не доказательство, это просто набор ничего не значащих фраз. Более того, вторая фраза («только дебил будет пытаться это опровергнуть») является демонстрацией применения Правила демагога №7.

Поэтому и опровергать здесь нечего.

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

Программы, которые пишут программы, это больше из кинофильма Матрица

А как же многоэтажные макросы, а кодогенерация, а главный аргумент про eDSL?

Надо? Настоящие суровые программисты пишут всё на С и считают, что его достаточно.

И таки пишут. Есть такая штука как impact, не знаю как можно перевести адекватно, наверное вклад, влияние. Так вот импакт какого-нибудь php, c или ruby, несоразмерно выше чем у лиспа. Лисп был большим шагом после ФОРТРАНа, только его использование сейчас не более чем фэнбойство. Возможно я сильно неправ.

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

Отлично, теперь примените это к своим постам и удивитесь.

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

А как же многоэтажные макросы, а кодогенерация, а главный
аргумент про eDSL?

Это имеет больше отношения к особенностям местной субкультуры, чем к реальной практике. За некоторыми исключениями это просто троллинг.

Так вот импакт какого-нибудь php, c или ruby, несоразмерно
выше чем у лиспа.

Ну и что?

Лисп был большим шагом после ФОРТРАНа

Между тем лиспом и Common Lisp общего символы да скобочки.

archimag ★★★
()

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

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

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

Вы не понимаете, что руководство не знает, что такое статическая типизация, выразительность и юнит-тестирование, а знает только про статистические показатели применения технологий X, Y, Z на рынках и кучу охуительных историй, испытанных на своем опыте или опыте коллег про разного рода технологических юродивых, пропагандистов и апостолов, проповедующих с интересами, совершенно параллельными интересам компании.

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

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

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

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

Это имеет больше отношения к особенностям местной субкультуры, чем к реальной практике. За некоторыми исключениями это просто троллинг.

То есть ты лично, ну или ваша контора, просто пользуетесь CLом как языком программирования без макров и прочил вкустностей типа кодогенерации? А ты один тянешь всю эту AI часть или есть коллеги? И как так получилось что на лиспе?

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

Я не говорил, что вот сейчас пишу код на CL за деньги. Раньше писал, но там вопрос о языке вообще не стоял, платили за продукт, а не за язык. Сейчас у меня есть некоторые эскизы на CL и я могу проводить сравнение с PyPy/CPython в плане скорости на моих задачах, но это чисто мои внутренние наброски. А так в проекте стандартно C++/Python/Javascript.

То есть ты лично, ну или ваша контора, просто пользуетесь CLом
как языком программирования без макров и прочил вкустностей
типа кодогенерации?

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

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

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

Я просто так понял из-за слов о коммерческой тайне и проч.

Раньше писал, но там вопрос о языке вообще не стоял, платили за продукт, а не за язык.

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

А так в проекте стандартно C++/Python/Javascript.

Как у всех :(

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

Осталось только понять, каким ветром вас сюда занесло?

Это человек-копипаста, он везде.

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

Мой вопрос был в другом, почему именно лисп и была ли команда?

Команда была, но она лисп не использовала, занималась другими вещами. В центре системы находился некий алгоритм, который было необходимо реализовать. Точнее, алгоритма то не было (иначе бы я просто написал его на C++), а алгоритм надо было найти, что бы результат в итоге устраивал бизнес. Т.е. основная сложность была не в том, что реализовать, а в том что бы найти реализацию, требовалось много экспериментировать с разными вариантами. Плюс, требования бизнеса изменчивы и видя результаты работы они постоянно вносят корректировки в свои требования.

Я написал первую версию на Python, но столкнулся с двумя вещами:

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

2. Скорость. Алгоритм работал медленно и мне приходилось долго ждать результатов работы. Что существенно замедляло разработку и вообще сбивало с «волны». Внёс небольшое изменение, запустил расчёт и пошёл курить.

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

Как-то так.

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

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

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

1. А можно пример на тему «интерактивной разработки»? Какой-нибудь случай опиши, например.

2. Мультиметоды тот же Александреску и реализовывает. Причем есть реализации, гораздо более эффективные чем у него(а многие реализации CL уступают даже этой реализации), в том числе, предложенные Страуструпом на основе статической двумерной таблички, генерируемой компилятором и линкером.

3. Протокол обработки условий из CL рассматривался при введении исключений в С++ и был отброшен, как бессмысленный, неэффективный, ненадежный и чреватый ошибками в реальных системах механизм. В D&E об этом написано, хотя и не слишком подробно. В результате они пришли к «обычным» исключениям, которые сейчас стали де-факто стандартом.

4. Макросы - путь к запутыванию кода. Да, я знаю макросы CL и понимаю, что это не С-макросы. Тем не менее, это все хорошо, пока ты пишешь один, но в команде они мешают больше, чем помогают. ИМХО.

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

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

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

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

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

Твою аргументацию можно свести к двум предложениям.

В С++ этого нет и никому не надо. Когда будет в новом стандарте вот тогда и посмотрим.

ИМХО

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

ИМХО, но С++ там как пример. И не «не нужно», а «можно сделать легко».

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

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

Не надо так нагло врать. Я читал Страуструпа. Дай точную цитату, а потом сравни со своим вариантом.

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

Подозреваю, что имеется в виду «семантика возобновления» vs «семантика завершения» при обработки исключительных ситуаций. Хотя там CL даже не упомянут конкретно, если правильно помню...

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