LINUX.ORG.RU
Форум — Development  

Лисперы, что я делаю не так?


1

3

Не религозного флейма ради. Хочется знать мнение именно людей кто использует лисп в повседневной работе.

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

Может я чего не понимаю и все делаю не так. Я в основном занимаюсь обработкой данных, моделированием, железки делаю на ПЛИСах ну там всякой фигней иногда. Для меня хватает С# плюс ANTLR и StringTemplate в качестве костылей когда надо сгенерить код. В четвертом дотнете есть Expression, ежели кодогенератор нужен в рантайме. Плюс это все статически типизировано и упрощает мне сильно жизнь, что возможно связано с моим малым объемом головного мозга. Кошер в виде сборки мусора, шустрого манагера памяти, всякого синтаксического сахара тоже в комплекте.

Прикинуть алгоритм очень удобно в вольфрамовой математике из которой выплевываю код в тот же С#.

Так вот вопрос, что люди (тысячи их!) делают на лиспе?

← C vs C++ скорость файлового вывода
Автоматическое построение UML диаграмм по исходному коду на C++ →

  1 2 3 4 →
Ответ на: комментарий от quasimoto

> Нету его :) Миллионы кода написаны на ANSI Common Lisp, наличие где-то полусырой библиотеки ничего не меняет. Кстати, нормальной реализации я не видел - всё потому что отдельно «паттерн-матчинг» не представляет собой ценности, он только одна сторона медали (или даже грань куба), а реализовать всё вместе и чтобы было как родное достаточно сложно.

ну в Racket вроде довольно неплохой паттерн-матчинг, не вижу причин реализации в CL подобного

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

> Т.е. есть класс «недопустимых дорожек» который нужно покрыть юнит тестами

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

дело вовсе не в типах, а в семантике.

mul1 :: Num a => a -> a -> a
mul1 x y = x * y

mul2 :: Num a => a -> a -> a
mul2 x 1234509876 = x
mul2 x y = x * y
korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

ну в Racket вроде довольно неплохой паттерн-матчинг, не вижу причин реализации в CL подобного

Я начал было делать, но пока оставил, т.к. задумался насчёт «востребованность» :) (кстати, там у меня мета-информация в виде тоер.-множественного языка не выделена как следует).

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

> Я начал было делать, но пока оставил, т.к. задумался насчёт «востребованность» :)

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

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

> в принципе да, особой надобности нет, обычно достаточно

простейшего паттерн-матчинга для списков


Да его тоже в итоге почти нигде не юзают. В коде SLIME есть реализация паттерн-матчинга, которая используется ровно в одном месте (смотрел год назад), при чём, с тем же самым успехом там можно было тупо и прямо за заюзать case ))

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

> Да его тоже в итоге почти нигде не юзают. В коде SLIME есть реализация паттерн-матчинга, которая используется ровно в одном месте (смотрел год назад), при чём, с тем же самым успехом там можно было тупо и прямо за заюзать case ))

по-моему для макр был бы удобен паттерн-матчинг как в схемовских макрах, стандартный macro-lambda-list (или как там его) слишком примитивен, имхо

korvin_ ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 →
← C vs C++ скорость файлового вывода
Development
Автоматическое построение UML диаграмм по исходному коду на C++ →