LINUX.ORG.RU

Выбор ЯП.

 


0

2

Привет.

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

В данный момент, хочется изучить что-то новое.

Полистал форум, после прошелся по вики, почитал про языки, которые более «симпотизируют», если так можно выразиться, собственно список:

  • OCaml, честно говоря, не знаю, что сказать, мнение не однозначное, очень мало библиотек, многое надо будет самому.
  • Go, очень напомнил python, с беглого просмотра исходных кодов, готового проекта. На первый взгляд понравился. Вроде активно развивается.
  • Scheme, и так потихоньку изучаю, по мере чтения sicp, но что-то писать на нем, думаю, только если для себя.
  • Erlang, думаю, это пока совсем не для меня, но ваше мнение хотелось бы услышать.
  • CL, так же как и со схемой, не обычно, не могу точно сказать, подойдет ли мне он.
  • Haskell, читаю очень поверхностно, но пока обхожу стороной.

Да, языки описал, а задачу собственно нет.

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

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

Извиняюсь, если все сумбурно и не внятно описал.

Заранее, огромное спасибо.

★★★

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

Достаточно S и K.

Не нужны, есть однокомбинаторные базисы.

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

То, что тебе не повезло с местом работы, это твои личные трудности. Так уж не надо валить свою обиду на остальные прикладные области, в том числе, которые требуют параллелизма.

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

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

anonymous
()

OCaml мой любимый язык, поэтому полюсую его, благо он всегда отличался огромным количеством библиотек.

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

Ырланк узко специализирован. Не думаю что с него надо начинать.

Лисподобные не очень уважаю, возможно я неосилятор.

На Go не кодил. Судя по тому, что видел --- не торт.

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

благо он всегда отличался огромным количеством библиотек

я считал, что у него с этим плохо.

SAA ★★★
() автор топика

лисп же, ну!

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

Ырланк узко специализирован. Не думаю что с него надо начинать.

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

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

Понятно, спасибо.

Кстати, по поводу scala, не хочется завязываться на jvm, если я все правильно понял.

Go убрал в сторону, ну и ocaml так же.

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

А правда, что большинство разработчиков на OCaml сбежали учить хаскель?

quantum-troll ★★★★★
()
Ответ на: комментарий от SAA

Тогда остается не так много.

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

Scheme. Идейно чиста. Куча реализаций. Хорошо встраивается в Си, но с библиотеками на самой схеме как-то не густо. Все таки язык чаще применяется именно для встраивания. Есть еще Racket. Вот он может быть самодостаточным. Но у меня сложилось впечатление, что Racket пишется в основном студентами и их преподавателями со всеми вытекающими плюсами и минусами.

Common Lisp. Безусловно самый практичный из всей этой нашей группы, если рассматривать только языки общего назначения, т.е. исключая Erlang. Если у вас нет ГУИ, то вполне можно обойтись свободными, читай, бесплатными реализациями SBCL и Clozure CL. А хороший ГУИ - только за деньги.

Haskell. Необычный язык. Очень высокий порог вхождения, хотя его идеи очень просты. Ну, тут как с математикой. Она тоже очень проста :) Есть куча неочевидных подводных камней, связанных с ленивостью, которые, наверняка, вылезут на многопоточной программе. Но платформа поддерживает зеленые треды как в Erlang. Еще есть STM. В общем, если осилите написать сложную программу на Haskell, то можете смело записывать себя в круг избранных. Кстати, я к нему не отношусь, если кто так мог невзначай подумать :)

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

Ну веб-сервер Ocsigen работает же многопоточно. Так что проблемы решили

А правда, что большинство разработчиков на OCaml сбежали учить хаскель?

Они уже вернулись обратно)

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

Спасибо за развернутый ответ.

Erlang, я уже понял, что он для более узких задач.

Schema, ее рассматриваю как поиграться для себя, во время чтения sicp.

CL, тоже из основных вариантов, но пока не определился. И да, гуй не нужен совсем.

Haskell, пытался начинать, но понял, что пока для меня рано.

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

лично для меня самыми странными вещами в haskell были lazy io причём только io, сама по себе ленивость была воспринята нормально, т.к. была небольшая теор база перед использованием языка. Понимание принципов работы монадических стеков.

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

qnikst ★★★★★
()

Без конкретной задачи все потуги изучить что-то новое практически бесполезны. Сначала найди/получи/придумай задачу, а затем очень критически подойди к выбору языка для её решения. Тогда довольно быстро всё само и найдётся.

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

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

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

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

там же, емнип, акторы на обычных тредах реализованы

В Scala есть thread-based и event-based actors. Последние не на тредах.

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

Класс задач, для которых нужен параллелизм - очень узок и уныл. Большинство реальных задач совершенно последовательны.

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

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

Унылые формочки будут унылыми только в учебном заведении. А на практике построение интерфейсов взаимодействия с пользователем — это не только дизайн, но и мощный background из служб и серверов их обеспечивающих. Источники данных становятся всё сложнее и сложнее, а желания пользователей всё шире и разнообразнее. Агрегирование информации, её классификация, автоматическая фильтрация скоро, очень скоро, будет хотеть всё больше и больше ресурсов, и всё больше и больше параллелизма.

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

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

Кстати, тут и всплывает оркестровка и рефакторинг информационных потоков. Без технологии параллельной обработки и асинхронных интерфейсов можно будет смело сливать воду.

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

не хочется завязываться на jvm
CL ... из основных вариантов

А ничего, что SBCL тянет за собой рантайма чуть ли не больше, чем JVM? Что используется JIT-компиляция, автоматическое управление памятью и garbage collector?

Может, пора всё-таки опираться на объективные данные, а не на мифы наподобие «Джава тормозит», «Лисп - это быстро», «Летательные аппараты тяжелее воздуха невозможны», «640КБ должно хватить всем», «Земля - плоская» и т.п.?

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

И еще, по CL, посоветуйте литерату, спасибо.

На мой взгляд по Common Lisp есть две хорошие книги для начинающих:

  • Practical Common Lisp, Peter Seibel, 2005. Она доступна бесплатно в интернете на английском. По-моему на lisper.ru есть русский перевод, но я его не читал.
  • Еще мне нравится книга ANSI Common Lisp, Paul Graham, 1995. В ней освещены темы, которых нет в первой книге. Например, описаны структуры и несколько вещей об опциональной типизации. Говорили, что готовится перевод книги на русский. Да и не смотри на год издания - ядро языка еще старее :)

А дальше обязательно Art of the Metaobject Protocol и другие книги, но это потом.

Еще можно попробовать начать изучение с книги Land of Lisp, Conrad Barski, 2011. Она очень прикольная и с комиксами, но я ее еще не прочитал, чтобы давать советы.

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

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

С этим вполне может справиться и Erlang. Им можно нагрузить ноду или группу нод так, что самым узким местом окажется даже не сеть, а подсистема ввода-вывода отдельных нод :) Но это всё решается правильной автоматизацией распределения заданий.

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

У Ocaml с многопоточностью не очень. Что-то фатальное со сборщиком мусора.

Не только со сборщиком. Также затруднена работа с потоками созданными не рантаймом окамла.

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

лично для меня самыми странными вещами в haskell были lazy io причём только io, сама по себе ленивость была воспринята нормально, т.к. была небольшая теор база перед использованием языка. Понимание принципов работы монадических стеков.

А меня в свое время «удивила» ленивость IORef.

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

Начать надо с клипа от авторов книги я:)

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

Ты только не забудь результат показать, ладно?

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

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

Да, конечно, код будет открытый.

ТЗ, собственно, ничего толком у меня в голове не сформировалось еще, только общие черты.

Как уже говорил, требуется продвинутый планировщик заданий, которые будет управлять хостами виртуализации(XEN). Основные его задачи, на данный момент:

  • Получение информации о хостах и виртуальных машинах;
  • Управление виртуальными машинами, думаю основные операции нет смысла перечислять;
  • Реализация API;
  • Мониторинг(но это чиста отдача определенных данных)
  • ...

Пока все это, очень размыто.

И не факт, что подойдет CL, я его совсем не знаю, возможно, в процессе, пойму, что нужно что-то другое.

В данный момент, половина функционала реализовано на Python.

SAA ★★★
() автор топика
Ответ на: комментарий от quantum-troll

У CL же регистровая ВМ, а не стековая, ведь так? Да и управление памятью будет другое.

От этого ЛNСП будет волшебным образом жрать памяти на порядок меньше, чем JVM? Дооооо.

Кстати, не надо забывать, что все приличные лиспы (не огрызки вроде ECL) тянут за собой в ОЗУ весь компайлер с потрохами. Не знаю, будет ли ТС счастлив от лишних 100 мегабайт рантайма.

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

ТС, ты смотрел на libvirt и virt-manager? Если да, то чем не устроило?

Да, конечно смотрел.

В данный момент использую XCP(Xen Cloud Platform), а libvirt с ним не дружит, вернее есть немного, но не то, что нужно.

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

Не знаю, будет ли ТС счастлив от лишних 100 мегабайт рантайма.

Сегодня читаю весь день про CL, как раз это и отталкивает, но 100 Mb, пока терпимо.

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

волшебным образом

Не волшебным образом, а за счёт грамотной архитектуры виртуальной машины (сравни jvm и dis, например).

тянут за собой в ОЗУ весь компайлер с потрохами

А вот это уже нехорошо.

quantum-troll ★★★★★
()
Ответ на: комментарий от SAA

как раз это и отталкивает

Я бы на вашем месте беспокоился не только насчёт этого, но и по поводу стыковки с XenServer API, с UNIX API и IPC, и по поводу проблем интеграции. И вообще, вы в курсе, как в Common Lisp сегодня обстоят дела с многозадачностью? Начинать надо с этого.

И, кстати, поведайте, откуда вы в такой задаче выкопали «много-много операций в секунду»? Тысячи виртуалок запускаете, что ли?

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

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

Типа, кучка авторов SBCL (там их четверо) придумали грамотную архитектуру, а целый штат архитекторов и разработчиков Sun Microsystems + Oracle не придумал? Ай лолд хардли.

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

И вообще, вы в курсе, как в Common Lisp сегодня обстоят дела с многозадачностью? Начинать надо с этого.

Нет, поэтому и просил совета, но плохо описал задачу.

И, кстати, поведайте, откуда вы в такой задаче выкопали «много-много операций в секунду»? Тысячи виртуалок запускаете, что ли?

Да, порядка 1000 виртуалок будет, это только в начале.

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

Я бы на вашем месте беспокоился не только насчёт этого, но и по поводу стыковки с XenServer API, с UNIX API и IPC, и по поводу проблем интеграции.

Над этим тоже думаю.

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

XenServer API

Проблем не будет, там обычный xml-rpc

UNIX API и IPC

Здесь, я думаю так же, не будет больших сложностей.

Изначально думал использовать OCaml, так как xapi(часть XCP), написана именно на нем.

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

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

Я пишу софт для контроля и обработки телефонных звонков, сервисы написаны на CL, для интерфейса с железом используется FFI. Все прекрасно работает на продакшене 24/7. Работающее приложение можно патчить вживую, подсоединяясь к REPL, очень удобно при откладке или апгрейде.

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

Так он вроде адекватный.

Я на самом деле пока остановился на CL, по мере изучение и написания, посмотрим, что получится.

Спасибо.

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

Я пишу софт для контроля и обработки телефонных звонков, сервисы написаны на CL

Ужель на SBCL или CCL?

используется FFI

Не показатель, на самом деле. Если какая-то реализация не поддерживает FFI, то впору задуматься над адекватностью реализации в частности, и языка вообще.

Кроме того, мой личный опыт показал, что использовать низкоуровневые биндинги через FFI — не самй оптимальный путь, т.к. скачки туда-сюда крайне напряжны для мозгов программиста и аппаратуры компьютера. Это я к тому, что с C все-равно придется очень и очень плотно разбираться.

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

Ужель на SBCL или CCL?

LispWorks конечно ;) Проект начинал на SBCL, но впоследствии вылезли феерические глюки с поддержкой тредов. Было это почти 2 года назад, с тех пор может пофиксили. А LW очень и очень хорош, все стабильно.

Кроме того, мой личный опыт показал, что использовать низкоуровневые биндинги через FFI

На С написана очень тонкая прослойка, только для вызова API железки с нужными параметрами. Макры генерят FFI код из описания этого API. Очень удобно.

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