LINUX.ORG.RU

Сериализация, десериализация данных и _кода_, с уклоном на кросплатформенность. Какой язык предложите?


0

0

python, Java, .NET - отметаются, моно - может быть, если оно умеет, с C# пока не сталкивался. В общем задача на много времени вперёд(несколько лет как минимум), поэтому языки типо JS, lua и прочего - отметаются. По этой же причине вопрос этот решаться будет неспешно, так как ещё финансирование не созрело. Принимаются только те языки, которые можно назвать зрелыми и универсальными. Не обязательно, чтобы поддержка была такая однозначно простая, как у динамических языков. Можно и с костылями, но всё же тащить с собой скажем gcc - не особо хочется:), хотя и можется. Также жизненно необходима интеграция(человеческая, а не марсианская) с С, так как на нём предполагается ядро и все базовые компоненты и это не обсуждается. Язык же с сериализацией кода будет работать поверх этой созданной платформы. Рассматриваю пока в качестве кандидатов: C(не совсем удобно, но привычно, хотя в некоторых случаях придётся тащить большой багаж), perl5(почти идеальный вариант и по портируемости и по удобству, но производительность - это проблема), perl6(тоже что и предыдущий, но более идеальный, однако производительность паррота пока говно, и не ясно будет ли толковый JIT, ну и ещё ракудо не созрел),CommonLisp(кажется, что идеал, в виде sbcl, но это язык с которым у меня нет опыта, однако это не проблема. Производительность видимо не проблема, раз компилируемый. Вопрос сразу к лисперам, как оно там, при значительном динамическом обновлении рабочего кода, ничего?).

Отдельно замечу, что проект будет по архитектуре чем-то напоминать emacs, другое предназначение совсем, но по архитектуре похоже. То есть 90% кода предполагается делать на том самом языке с сериализацией кода. Зачем это нужно? - для динамического обновления приложения, изменения его логики на лету и тд. Для данного приложения это жизненно необходимо. В отличие от емакса будет более модульно, из микрокомпонент, но это не суть важно, в контексте сабжевой задачи можно считать просто, что 10% кода это некая программа на С, которая загружает некоторый кусок(90%) на другом языке и общается с ним. Что порекомендует всезнающий олл? Вопрос прежде всего к тем, кто имеет не теоретические, а практические знания.

PS: фанатов языков прошу не беспокоить, до известного предела я готов посмотреть на какие-то варианты, но только до известного предела.

★★

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

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

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

>> Smalltalk

Вот и некрофилы подтянулись.

Ути ути ути, он как обгонял своё время 30 лет назад, так и сейчас обгоняет

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

Как часто говорят в симпсонах - «моя ошибочка». Просто нечёткая формулировка первого поста и усложнила задачу всем, каюсь за это.
Стримить, да, но не только. На мобильные девайсы - да, но не мобильники:) Отталкиваться от фирмвари, ну речь шла про выньтел, линьтел и армлинь в основном. Вопрос ускорения декодирования, шифрации и прочего аппаратными средствами не рассмаривается как основной, только в том случае, если оно есть, а есть не везде, поэтому это за рамками топика.

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

Вообще трудно советовать какой-либо язык не зная хотя бы сферы решаемой задачи :)

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

>ну речь шла про выньтел, линьтел и армлинь в основном.

Тогда часть советов в топике уже мимо - sbcl под «выньтел» нету, например. Да и эрланг с явой вы там не заведете.

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

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

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

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

Аааааа. Что-то вроде вот этого?

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

Интересная ссыль, но к счастью не подобие и что ещё важнее - не для массовых нужд, и так уже там велосипедов хватает:) Частично пересекается, но это точно не будет в виде одного гламурного окошка с интегрированным туда всем, что попало. Компонентность и динамизм нужены ещё и потому, что в большинстве случаев каждая функция пользователю будет предоставлена отдельно и даже в разное рабочее время. Разные люди будут выполнять разные задачи и как следствие им будут доступны разные функции системы(кому-то доступ к файлам, кому-то доступ к базе определённых предметов-товаров) ну и тд.

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

куда слать резюме?

эта вакансия уже закрыта, вообще-то

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

Вы много видели реализаций видеокодеков, алгоритмов сжатия на интерпретируемых языках?

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

Если же вопрос ставить о клее, то скорее будет выбор в сторону Java для всего проекта, но это выходит за рамки топика.

не вполне очевидно, но хозяин - барин

архитектура подобная по духу DBus

можно поинтересоваться - какая?

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

что это за пруф такой где не выкинутый вами тикль и перл сливает тормозной луа в десяток раз?

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

> Прекратите препирательства

Ты так говоришь, будто я единственный тут препираюсь %)

скажите что-нибудь более ценное для ТС.

ТС'у я сказал всё ценное, что хотел. При такой мутной формулировке задачи больше сказать было невозможно.

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

что это за пруф такой

какой есть, не нравится - нагуглите свой, сравним :)

где не выкинутый вами тикль и перл

с какого перепугу это я их должен вкидывать?

что это за [..] где не выкинутый вами тикль и перл сливает тормозной луа в десяток раз?

1) потому что так оно и есть, на каких то приложениях может и иной расклад, но на приведённых в пруфе - очень похоже, бьётся с результатами на debian.shootout. не верите? код есть, языки доступны - велкам, перепроверьте

2) ну и раз уж Вы начали - обоснуйте тормознутость Lua

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

>обоснуйте тормознутость Lua

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

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

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

:) ну топикстартер и правда насчёт некоторых вещей загибает щота, но это его право

в приведённом пруфе Lua как раз достаточно бодро вертится :)

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