Racket 6.7

Обычно мозг вещь не популярная...

JIT компиляция хороша в основном для программ которые работают как сервер. В остальном интерпретатор с нативными C модулями намного приятнее.

Хипстота от 1978 до современности? Или когда там стали популярны идеи Хоара? Go - лишь проекция идей Хоара на язык со сборкой мусора, который имеет C подобный синтаксис.

А до go разве был компилииуемый язык с CSP на уровне синтаксиса? Сборка мусора тут не главное, кмк, всех подкупило то, что он быстрее пхп

Ну этот ваш лисп, пойду быдлокодить на пыхе, ишь, задроты лиспофф придумали!!111 Да и вообще, пых — рулез, ибо он прАаастой!!!1111

Гоу

Под Plan 9?

из семейства Lisp/Scheme
не набирает популярность

Ну кто бы мог подумать, и почему же?

Если под убогостью ты понимаешь простоту и императивность то он таким задуман.

Ну кто бы мог подумать, и почему же?

Потому что ещё есть Chicken Scheme компилятор в C, другие реализации. Несколько компиляторов Common Lisp, но их всех отодвигает на задний план SBCL, за счёт быстрого кода.

Chicken Scheme вообще уникальная вещь, но из-за особенностей реализации невозможна работа с native threads, только процессы.

Фишка в сборке мусора в том числе. Когда плодишь множество потоков память будешь жрать тоннами, и всего одна утечка может привести к неприятным последствиям очень быс

Фишка в сборке мусора в том числе. Когда плодишь множество потоков память будешь жрать тоннами, и всего одна утечка может привести к неприятным последствиям очень быстро.

Ну может php'шники перебежали «заодно».

Сборка мусора это ладно. Но ведь реально не было до Го языка с простой и понятной встроенной многопоточностью. Хотя потребность в этом назрела еще с тех пор как постановка «лайка» или написание комента перестала перекидывать пользователя на новую страницу

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

Несколько компиляторов Common Lisp, но их всех отодвигает на задний план SBCL, за счёт быстрого кода.

LispWorks цивилизованней в плане стабильности.

Erlang не сложнее Go, он лишь имеет другой синтаксис слегка, да малость тормозные строки (не бинарные).

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

Чем Scala не устраивает?

Future {
  longRunningExecution
}

Ничем не сложнее горутин.

А Chez смотрел?

Про Clojure сложно сказать, я на нём не писал.

Принципиальная невозможность оптимизации хвостовой рекурсии. «ФП язык» тоже мне...

LispWorks цивилизованней в плане стабильности.

Personal Edition работает только с 32-битной версией libgtk-x11-2.0

Error during GUI startup:
  Could not register handle for external module "-lgtk-x11-2.0":
 libgtk-x11-2.0.so: wrong ELF class: ELFCLASS64.

По легкости использования лучше всего Clozure CL.

А Chez смотрел?

Реализация открыта с весны. Не смотрел ещё. Racket быстрее чем Chez http://www.larcenists.org/benchmarksGenuineR6Linux.html

После Chicken Scheme врядли будет что-то очень интересно. Chicken единственная реализация которая использует все преимущества CPS(continuation passing style), на этом принципе работает компиляция в C и быстрый и точный компактирующий GC.

Несколько компиляторов Common Lisp, но их всех отодвигает на задний план SBCL, за счёт быстрого кода.

LispWorks цивилизованней в плане стабильности.

Мне LispWorks тоже больше всего понравился, и самой средой и лисп-машиной. Еще должен быть крайне интересен Allegro CL.

Но тем менее, честную оптимизацию хвостовой рекурсии умеет только SBCL. Впрочем, для Common Lisp она не так и важна.

Мне LispWorks тоже больше всего понравился, и самой средой и лисп-машиной. Еще должен быть крайне интересен Allegro CL.

Это enterprise платформы, с дорогими лицензиями. Что там может быть интересного..

Отладчик, библиотеки, CAPI, Graphics Port. LispWorks работает надежно как часы, по крайней мере, если его правильно использовать, насколько это можно сказать про язык с динамической типизацией. Вылетал и зависал, конечно, но это из-за моих действий. Да и мне сама среда понравилась даже больше, чем Emacs + SLIME, да тот же отладчик и просмотрщик объектов.

К тому же, LispWorks умеет прекрасно интегрироваться с ASDF и QuickLisp. У меня есть один долгоиграющий проект-хобби, так там у меня все сделано через ASDF + QuickLisp.

Плюс, у LispWorks просто шикарная документация как в виде HTML, так и виде файлов PDF с красивыми шрифтами. Мне очень нравится, когда документация в PDF с поиском и индексом. Не люблю я этот вездесущий HTML.

Да, рюшечки мне тоже нравятся, но главное, это надежная лисп-машина. К SBCL такого доверия у меня нет, да и к CCL - тоже, но это личное)

Цена смущает. Это есть.

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

Это enterprise платформы, с дорогими лицензиями. Что там может быть интересного..

Стабильность, мощный механизм delivery, кроссплатформенность, нормальная гуёвая библиотека, etc...

Чего только на лоре не увидишь.

LispWorks - английский продукт

Американцы или британцы?

Chicken единственная реализация которая использует все преимущества CPS(continuation passing style)

Это означает что возможны хорошие green threads?

Британский.

Годно, приятно видеть, что оно не умерло

Это означает что возможны хорошие green threads?

Это первое что приходит на ум когда читают про Continuation Passing Style, green threads есть на скорости C.
Но в Chicken Scheme это ещё GC полностью на основе CPS: http://www.more-magic.net/posts/internals-gc.html

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

Один из немногих ЯП, свежие релизы которых я всегда беру и ставлю без всяких сомнений.

Правильно, нужно. Развивают себе последовательно. Удобно и приятно пользоваться. Так держать, Racket.

шта? мамкин лингвист не в теме, но зато в треде? :)

Это первое что приходит на ум когда читают про Continuation Passing Style, green threads есть на скорости C.

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

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

fix

bernd

Дата регистрации: 08.04.2007

Дайте человеку потроллить!

О каких идеях Хоара идет речь?

Кстати, если меня память не обманывает, был трабл с картинками, зашитыми в сорцы, при компиляции под некоторые ОС. Починили? А то реально, оперирование картинками, как литералами - киллерфича языка. Я даже узал его на одном зимнем icfpc только потому, что на выходе надо было получить картинку и было мегаэпично в самом конце набрать команду в REPL, нажать энтер и в консоль плавно выполз кадр из фильма, название которого было финальным ответом соревнования. Гораздо круче, чем подрубать либу, записывать в файл и открывать его в чем-то.

Ты знаешь, в моде. Просто вот есть язык. Для своих задач. Хороший. В модные нынче «холивары» нормальным людям нечего влезать. Это как спорить, что лучше - вареная или копченая колбаса.

Хипстеры, шмипстеры, да кто угодно - пусть пишут на чем угодно.

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

Опять же - какие задачи решать.

ПыСы: Clojure

<<«пизьдюк тьі малолетний, вот тьі кто»/utf8>>

Erlang

отстой. Строки гавно, постоянные дедлоки + динамическая типизация добавляет попоболи. И все это при скорости сравнимой с питоном.

CSP же. Общение по каналам между процессами.

Дедлоки могут быть лишь от ошибок в коде.

Erlang медленее питона почти в любой задаче. Медленее в математике, обработке строк.

Зато шустрее в многопотоке и обмене сообщениями и обработке бинарных последовательностей.

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

А динамическая типизация - ну а кто её любит.

Кстати, если меня память не обманывает, был трабл с картинками, зашитыми в сорцы, при компиляции под некоторые ОС. Починили?

Это если и было, то починили давно.

Сейчас единственный аргумент против картинок и прочих псевдоэлементов в сорсах — прочитать их можно только через DrRacket. Более того, желательно той же версии (формат, конечно, давно не менялся и новые версии DrRacket читают старый формат, но в старом DrRacket новый .rkt может не открыться). Поэтому картинки в код вставляют либо в учебных программах, либо в intranet'овских.

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

Это если надо конвейером обрабатывать накопленные данные на нескольких ядрах. Но «green threads» в виде корутин для моделирования беспрерывной системы акторов с (псевдо)случайными входными данными, абстракция над стеком. Эта модель лучше работает на одном ядре где не нужно использовать mutex/semafor, для ограниченного кол-ва акторов, как в играх. Она реализуется даже на C через Duff's device(switch) как в Protothreads: http://dunkels.com/adam/pt/

Дедлоки могут быть лишь от ошибок в коде.

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

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

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

Дак надо писать в традиционном стиле.

В традиционном это как? fork/exec на каждое соединение?

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