LINUX.ORG.RU

помогите выбрать ЯП


0

0

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

* сборщики информации
* действия
* диспетчер (получает информацию от сборщиков и вызывает соответствующие действие).

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

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

Хотелось бы получить максимальное удовольствие от разработки, остальное все не так важно. Буду рад выслушать советы по выбору языка от уважаемых лоровцев. Опыт с ЦЛ у меня был лет 7 назад, на эрланге не программировал никогда.

★★★★★

Ну вообще вопросы. Ты бы ещё спросил на лоре: с кем провести новогодние праздники — с Машой или с Леной.

anonymous
()

глянь gtalk.

anonymous
()

Я один заметил, что за последние 1.5-2 недели количество топиков «помогите выбрать ЯП» резко увеличилось? К чему бы это?

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

По теме:

Ты задал очень правильный вопрос, потому что у тебя в нём даже больше половины ответа.

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

Но и в реализации всего описанного тобой на CL тоже есть свои «вкусняшки». :) Я сам на scheme (Racket) нечто подобное в свободное время набрасываю, только не такое комплексное (задачки помельче).

OldFatMan
()

хаскел отпадает ибо я слишком туп для него

Ладно бы из-за горячей замены, но конкретно это — совсем смешная причина.

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

хаскел отпадает ибо я слишком туп для него

Ладно бы из-за горячей замены, но конкретно это — совсем смешная причина.

Вы своими монадическими трансформерами всех распугаете.

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

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

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

Вопрос был задан...мнэээ...не вполне серьёзно. И кстати, ТС совершенно правильно на него отреагировал.

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

Не спорю. Впрочем, о возрасте ТСа ничего определённого сказать не могу. Лично не знаком.

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

А это чем же настораживает? Чем такой человек хуже других вопрошающих?

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

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

anonymous
()

получить максимальное удовольствие от разработки

Eiffel

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

настораживает тем, что кажется что у людей создается впечатление, что разработка медом намазана

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

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

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

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

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

Да это ж он не про тебя.

Про тебя - вот:

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

Если ты, конечно, «молодёжь». :)

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

я не про Вас имел в виду. Я имел в виду взрослого человека из абсолютно другой профессии. Кстати в юности я был железнодорожником :))))))))

Vernat ★★
()

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

С чего это ты взял?

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

Кстати в юности я был железнодорожником

А я, кстати, в юности был инженером-строителем пректировщиком. Хотя и расчётную часть диплома уже запрограммировал. ;)))

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

s/пректировщиком/проектировщиком/

Тьфу, опять ачепятки пошли. Видима-а, спать пора... ;)

OldFatMan
()

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

можно попробовать php, если интересен конечный результат.

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

> С чего это ты взял?

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

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

> Рыжик был лучше, я умилялся, глядя. :)

Хорошо, надоест лок, поставлю рыжика обратно :)

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

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

У тебя не такая задача, явно. Не нужно кучи тредов, достаточно асинхронности.

Нет, если интересно, можешь конечно и эрланг взять. Только он ничем не будет лучше других вариантов. К тому же у него vm толстовата.

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

> У тебя не такая задача, явно. Не нужно кучи тредов, достаточно асинхронности.

Нет, я понимаю, что тут и обычные треды будут достаточны, и даже наличия ГИЛа каши не испортит. Просто меня заинтересовало, что в эрланге обмен сообщениями между процессами реализован на уровне языка. Конечно, не имея практического опыта я не могу определить насколько это удобно и приятно.

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

CL
Хотелось бы получить максимальное удовольствие от разработки, остальное все не так важно. Буду рад выслушать советы по выбору языка от уважаемых лоровцев. Опыт с ЦЛ у меня был лет 7 назад

Попробуй racket — cовременный лисп. Оч. приятный ЯП.

kermzyxer
()

erlang. Там не скобочек. Кроме того для задач, которые ты перечислил подойдёт очень хорошо.

nanoolinux ★★★★
()

мониторилку эвентов в системе

шелл. Все события посылать на почту и смотреть штатным почтовиком. Главное, событие «почта пришла» не зациклить.

ugoday ★★★★★
()

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

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

Горячая замена есть, не надо тут дезу постить.

То есть можно в дебаггере аттачнуть любое работающее приложение на хацкеле, заменить бажную функцию на новую, деаттачнуться и радоваться жизни? Нельзя.

anonymous
()

если хочешь сделать что-то реально рабочее - С, если хочешь просто «вбить время» - CL, Erlang и пр.

anonymous
()

Smalltalk, Haskell, Omega, Coq, Agda2, Epigram.

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

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

В статически типизированных языках горячей замены быть не может.

Очень сильное утверждение. Смахивает на 4.2.

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

> > Горячая замена есть, не надо тут дезу постить.

> То есть можно в дебаггере аттачнуть любое работающее приложение на хацкеле, заменить бажную функцию на новую, деаттачнуться и радоваться жизни? Нельзя.

Механизмы разные есть. Ты вообще что сказать-то хотел?

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

Нет, ну вот: f = 1, g x = x + f, f = «SOOSNOLEY», g 10 - и каков же будет результат в статически-типизированном ЯП? Если мы можем сделать вот такую вот горячую замену, то нарушаются типовые инварианты. А если они нарушаются - ЯП уже нихрена не статически-типизированный, по определению.

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

Это не содомия, это и называется «горячая замена». Была глючная функция - мы взяли и переписали ее, заменив неглючной. Не вырубая приложение. Конечно же, какая функция окажется глючной - мы заранее не знаем, а потому предусмотреть средства, который бы позволили эту неизвестную заранее функцию заменить - не можем. Вообще говоря, в теории горячую замену для статики делать можно - для этого надо надо уметь в типы как first-class values и сделать какой-то не совсем понятный механизм, примерно аналогичный реификации в .net. Программа во ремя рантайма должна будет существовать в двух экземплярах - собственно то, что исполняется, и некое высокоуровневое представление + какой-то механизм эффективной синхронизации первого со вторым. Насколько реально все это реализовать даже для простых систем типов - неизвестно.

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

Нет, ну вот: f = 1, g x = x + f, f = «SOOSNOLEY», g 10 - и каков же будет результат в статически-типизированном ЯП?

g захватит первый f и всегда будет иметь смысл (\x -> x + 1). При горячей замене можно переопределить f, но это не скажется на g, чтобы сказалось нужно обновить и g тем самым запустив тайпчек отношения f <-> g и проверив инварианты. Т.е. в любом случае горячей замене что в динамическом, что в статическом языке нужен доступ к реализации - либо сидящей в образе вместе с приложением (как в CL), либо лежащей отдельной библиотекой (как в Haskell).

В Haskell горячая замена обычно делается с помощью парсера (GHC API / haskell-src), API реализации (GHC API) и front-end-а осуществляющего такую замену (примеры - GHCi, plugins).

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

некое высокоуровневое представление

То есть все полиморфные функции - первоклассные объекты на уровне реализации.

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

g захватит первый f и всегда будет иметь смысл (\x -> x + 1).

Я в курсе.

При горячей замене можно переопределить f, но это не скажется на g, чтобы сказалось нужно обновить и g тем самым запустив тайпчек отношения f <-> g и проверив инварианты.

Вот именно. Нам нужно остановить и перекомпилировать все приложение. Иначе - в хаскеле никак.

Т.е. в любом случае горячей замене что в динамическом, что в статическом языке нужен доступ к реализации - либо сидящей в образе вместе с приложением (как в CL), либо лежащей отдельной библиотекой (как в Haskell).

Не знаю, о чем ты говоришь. Я просто пишу:

> (define (f) 1)
> (define (g x) (+ (f) x))
> (g 10)
11
> (define (f) 10)
> (g 10)
20
> 
И все работает.

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

Еще раз - заменить ф-ю _можно_, но вот только в этом случае сохранение типовых инвариантов тебе никто не гарантирует. Во многих случаях - это гарантированный сегфолт при запуске (ведь у нас же статически типизированные языки из соображений оптимизации тип аргумента не проверяют, так?), не говоря о нарушении семантики. И ЯП надо тогда уже де-факто не статически типизирован, а динамически.

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

В Haskell горячая замена обычно делается

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

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