LINUX.ORG.RU

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


0

0

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

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

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

★★

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

Ответ ожидаемый, однако что касается ООП, то с головой для данного проекта хватит того, что есть в gobject. А если захочется проиграться с шаблонами, но по этой части больше склоняюсь к возможностям CL или перла. Что же касается сериализации и десериализации кода, то ситуация полностью аналогична C, то есть тащить с собой надо компилятор. Не то чтобы это проблема, это даже не проблема, но некоторое неудобство.

ixrws ★★ ()

Я знаю один похожий проект, называется он www, так там мужики js используют. Проект рабочий, пользователей миллиарды. Но тебе конечно виднее, ты js с порога отмел, наверное мужики чего-то не знают.

anonymous ()

>Зачем это нужно? - для динамического обновления приложения, изменения его логики на лету и тд. Для данного приложения это жизненно необходимо. В отличие от емакса будет более модульно, из микрокомпонент

Явно напрашивается эрланг - он в том числе под это заточен.

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

Очень разное применение. Да, вариант с xulrunner допустим мог бы теоретически быть рассмотрен, но существенная проблема в производительности. В иделе она должна быть сопоставима с С, то есть в этой части мне знаком только CL, который компилируется, по этой же причине упомянул моно, он тоже неплох.
Мужики пишут хороший и не очень код, который более-менее выполняет свою задачу. Но когда на JS напишут допустим файловую систему, тогда меня и позовёте, тогда да, сможете сказать что им что-то виднее, а мне нет.
Задача тех 90% во многом это ресурсоёмкая работа, а не отклик на кнопочки по требованию. В общем это как если бы в емаксе была реализация фс на елиспе, браузер полностью на елиспе и тд.

ixrws ★★ ()

CommonLisp(кажется, что идеал, в виде sbcl, но это язык с которым у меня нет опыта, однако это не проблема. Производительность видимо не проблема, раз компилируемый. Вопрос сразу к лисперам, как оно там, при значительном динамическом обновлении рабочего кода, ничего?).

Процессору фиолетово, как часто код обновляется. Лисп (sbcl) заведомо лучше перла, ибо выдаёт очень быстро работающий код. Плюс сериализация/десериализация из коробки. Интерфейс к Си (CFFI) простой, как тапок. А если проект на много лет, то относительно лёгкая возможность расширения компилятора тоже плюшек может дать. Правда, это sbcl-зависимое. На неинтересных платформах, где sbcl не работает, либо работает плохо, можно использовать вездеработающий clisp.

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

Пасибо, будем глядеть, а кросплатформенность у него как? Впрочем надо глядеть.
И да, я понимаю, и так уже архитектура полна извращений, но приложения должны будут взаимодействовать с разных архитектур как программных, так и аппаратных. По началу это как минимум linux|windows и x86|arm.

ixrws ★★ ()

Ты отмёл питон, но при этом:

Принимаются только те языки, которые можно назвать зрелыми и универсальными.

Также жизненно необходима интеграция(человеческая, а не марсианская) с С, так как на нём предполагается ядро и все базовые компоненты и это не обсуждается.

Это всё как раз есть питон. А также сериализация и десериализация в питоне вполне по теме.

И да, упоминание perl6 в контексте «зрелого и универсального» - это даже не смешно.

anonymous ()

С динамическим обновлением кода в лиспе все в порядке. А вот с сериализацией кода чуть сложнее — в лиспах можно сдампить только образ целиком целиком (да и то предварительно завершив все нити, кроме одной - не зря же в sbcl функция называется save-image-and-die). SBCL, в принципе, можно допилить до того, чтобы можно было сериализовать отдельные функции (но они, очевидно, не будут переносимы на другую платформу или другую версию sbcl).

Еще замечание - лучше держать исходную форму кода отдельно (например, в лиспе можно s-expr'ы хоть в БД класть) и компилировать (с кэшированием компилированного кода). Исходный сериализовать проще, да и «правильно» это.

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

не зря же в sbcl функция называется save-image-and-die

save-lisp-and-die!

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

Вот кого в треде я и ожидал, спасибо. Что до sbcl, да, он во многом основной вариант, потому что боюсь интерпретация просто не потянет, проект на perl или clisp вероятно не будет ворочаться приемлемо, будет работать хуже флеша:) Поэтому вопрос, как с поддержкой платформ, _реальной_ ?. Пока интересует arm|x86 и linux|windows. Возможно будет ещё mips и другие никсы, нежели linux, но это явно не завтра и даже не через год.

Ту ол: Хочется отдельно пояснить, что вопрос производительности крайне важен, имменно он и заставил сомневаться в перле. Просто в рамках поставленного вопроса будем считать, что речь идёт о коде, сопоставимом с тем, что есть в крупных проектах, написанных на C или C++. Допустим xulrunner, Qt, imagemagick, http серверы.

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

А вот с сериализацией кода чуть сложнее — в лиспах можно сдампить только образ целиком целиком

По-моему, ты не так ТС понял...

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

С кроссплатформенностью у него ок, а вот arm - на дохлом(в плане производительности/аппаратной обвязки) железе могут быть проблемы(на rsdn кое-кто пытался применять эрланг в embedded).

Я бы выбрал лисп или эрланг, но тут уже все сильно от задачи зависит.

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

Это мне всё известно, но будем считать что пистон отметён из-за неприятия коммандой, будем считать что это вопрос религии. Но даже в этом случае, этот вопрос на 2м месте, потому что и перл и пистон отфильтрованны как минимум с точки зрения вопроса скорости работы.
Что до perl6, то в первом же посте я упомянул его проблемы, но он очень вкусный, хотя ещё и не родившееся дитя.

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

Поэтому вопрос, как с поддержкой платформ, _реальной_ ?. Пока интересует arm|x86 и linux|windows. Возможно будет ещё mips и другие никсы, нежели linux, но это явно не завтра и даже не через год.

SBCL лучше всего на x86 под юниксами работает. Под виндой нет тредов, но dmitry_vk решением этой темы сильно заинтересовался. Будем надеяться на хэппи энд. Под arm бэкенда нет. Кто-то время от времени что-то делает, но результата рабочего нет. Если у arm'а было бы 32 регистра, то переделка другого похожего бэкенда (ppc, mips, alpha) была бы тривиальной задачей.

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

Для arm'а можно попробовать clisp или gcl/ecl.

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

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

Тогда бери тот же sbcl - вполне себе mature компилятор; впрочем, насколько он полноценно работает под виндой поспрашивай у более опытных лисперов.

//anonymous с эрлангом

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

> Под виндой нет тредов, но dmitry_vk решением этой темы сильно заинтересовался

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

Для arm'а можно попробовать clisp или gcl/ecl.

А всякие коммерческие реализации с шахматами и машинистками?

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

А всякие коммерческие реализации с шахматами и машинистками?

Коммерческие реализации стоят очень коммерческо. И всё равно под arm не работают ;)

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

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

ixrws ★★ ()

Да никакой разницы. После «платформа» и «напоминать emacs», предрекаю этому неизвестному проекту тихую незаметную смерть задолго до рождения.

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

Хм, тредов нет это в общем незадача, хотя раз есть доступ к С простой, то насколько я понимаю приклепать треды будет несложной задачей. Что ж, будем надеяться.
С арм жаль, но буду копать, ибо всё равно очень интересно. А случайно могут найтись те, кто за донейты запилят поддержку арм, гипотетически?
А x86_64?
Что до clisp, то арм и так не самый быстрый, боюсь что часть приложения, работающая на каком-нибудь фрираннере будет настолько аццко тормозить, что просто нет смысла.

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

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

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

И ещё спасибо, что повелись на слово емакс. Речь шла лишь о соотношении процентов кода на разных языках и их взаимодействии, не более того.

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

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

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

А случайно могут найтись те, кто за донейты запилят поддержку арм, гипотетически?

По-идее, один 16-регистровый бэкенд уже есть, можно бы с него содрать. В любом случае, даже для шарящего чувака это около года работы. В принципе, тема эта в виду роста мощи армов интересная, и я думаю, что когда-нибудь sbcl будет и arm поддерживать.

А x86_64?

Есть, я под x86 подразумевал и ia32, и x86-64.

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

> Спасибо за оптимизм и веру.

Не за что. Для долгоживущего проекта отметены Java (хотя она точно переживет сабжевый проект) и Lua (маленький интерпретатор байткода, который можно просто форкнуть в случае смерти апстрима), но ведется типа серьезный разговор о SBCL %) Это всё намекает...

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

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

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

Конечно, на фанатизм, экстремизм, максимализм, неокрепшую психику, молоко на губах, что там ещё дальше по списку?
Поэтому да, подобные вашим посты предполагались изначально, это естественно, правильно. Было бы неправильно, если бы никто не написал об этом.

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

Последний вопрос, щарящий человек и год работы - сколько это в американских правителях?

Лучше кого-нибудь в Европе на part time нанять, дешевле будет :) Ну и хз, чё там по бабкам. Тыщ за 20-30-50 евро сделают, поди.

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

Для долгоживущего проекта отметены Java (хотя она точно переживет сабжевый проект)

Почему тогда не Кобол или Фортран?

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

Не современно же. Сейчас для крупных проектов современно только Java и C# на .NET.

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

>> Для долгоживущего проекта отметены Java (хотя она точно переживет сабжевый проект)

Почему тогда не Кобол или Фортран?

Ты чо, отощал там в своих европах? %) Если бы сейчас был 1970-й, то Фортран или Кобол, без разговоров. Но вроде 2010-й уже, не? И Java - это прежде всего JVM, на которой языков - вагон и еще тележка. И все с тредами, с тредами :-P

Это не говоря о Lua и прочей простой и понятной мелочи типа тикля. Или своего языка (если уж проэкт такой большой и крутой).

P.S. в этом вашем SBCL байткод хоть есть, или по сети сырцами обмениваться?

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

Ты чо, отощал там в своих европах? %)

А ты, я смотрю, в отпуск, что ли, ходил? На ЛОРе не троллил, загорел, жирок наел, дерзкий стал ;)

P.S. в этом вашем SBCL байткод хоть есть, или по сети сырцами обмениваться?

Конечно, сырцами.

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

Во, совсем забыл! Под венду OpenMCL с тредами есть. Компилирует, конечно, похуже SBCL, но тоже ничё так. Под линукс и макось тоже есть.

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

Фантазии такие фантазии. Какой-то большой, крутой. О чём вы? Неудовлетворённость жизнью? Разговора ведь такого не было!
Свой язык не рассматривается, в этом нет необходимости, на крайний случай даже таскание c собой gcc не страшно.
Что до обменивания по сети - это тоже не важно, код не будет слаться непрерывно. Просто переодическая пересылка. Да и компрессию и шифрацию никто не отменял.
PS: Тоньше, ещё тоньше.

ixrws ★★ ()

Вам может подойти любой язык, если использовать библиотеку JSON/XML/binary сериализации. Такое в Java и .NET out of the box, в других языках не знаю.

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

> Фантазии такие фантазии.

Ты об этом?

задача на много времени вперёд(несколько лет как минимум)

отметаются.

Принимаются только те языки, которые можно назвать зрелыми и универсальными

у меня нет опыта, однако это не проблема.

фантазии, да :D

на крайний случай даже таскание c собой gcc не страшно.

Даже не знаю, как это назвать %)

Неудовлетворённость жизнью?

Нет, опыт и здравый смысл. А моя профессиональная жизнь меня пока вполне устраивает, спасибо за беспокойство :)

tailgunner ★★★★★ ()

Офигеть, lua и js для них незрелые, питон отвергается по религиозным причинам, зато мертворожденный perl6 и поддерживающий 1,5 платформы sbcl рассматриваются как кандидаты. Прозреваю команду мега-профи!

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

>> Спасибо за оптимизм и веру.

Не за что.


Требования к квалификации:
• Среда разработки: Unix(Linux), Emacs, Trac, RedMine, GIT, SVN, DARCS
• Программирование: Функциональные языки(Erlang/OTP, Lisp, Haskell, Scheme, Prolog)
• Базы данных: SQL92, MySQL, PostgreSQL
• Веб-технологии: JavaScript (JSON, AJAX, JQuery, Prototype), HTTP/HTML/XML, PHP, ASP.NET, Фреймворки(Nitrogen, RubyOnRails), Flash
• Веб-серверы: Apache, Nginx, MochiWeb, Yaws
• Методология разработки: RUP, XP, SCRUM, Тестирование


Должностные обязанности:
• Разработка веб серверного многопользовательского программного обеспечения
• Проектирование баз данных
• Разработка тестовых сценариев
• Верстка и оптимизация веб приложений

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

>Во, совсем забыл! Под венду OpenMCL с тредами есть. Компилирует, конечно, похуже SBCL, но тоже ничё так. Под линукс и макось тоже есть.

+1, теперь его зовут clozure cl, но работает он только на x86 и powerpc, есть еще clojure - лисп для jvm, все плюшики явы в комплекте плюс много своих, но как оно с arm мне неизвестно.

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

Время не значит объём и не значит крутость. В том контексте означало лишь то, что есть время ознакомиться с разными решениями и выбрать. Что до опыта, красиво выдрано из контекста, да. Однако вы начинали работать сразу с опытом? Родились? Или переходя на использование другой технологии сразу имели с ней опыт, врождённый? Впрочем вопросы не требуют ответа:)

Даже не знаю, как это назвать %)


А чем принципиально это отличается от таскания с собой jvm? Даже по объёму в мегабайтах как-то нет профитов у jvm существенных. Задача же вполне решается с помощью С + компилятора с собой. Да, не элегантно, это да.

Нет, опыт и здравый смысл. А моя профессиональная жизнь меня пока вполне устраивает, спасибо за беспокойство :)


Очень хорошо что устраивает, а то я уж начал беспокоиться, а теперь прямо как камень с души.

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

Наркоман штоле, что это за фигня?

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

Читайне внимательнее, аноним. Lua и js не названы незрелыми, у них со скоростью проблемы, даже у v8. sbcl же компилятор, со всеми вытикающими от сюда. Да, к луа прикручивают джит, ну чтож, посмотрим потом. Питон тоже пилят на предмет скорости, может через несколько лет он будет готов. Про перл ясно написано что там не так.

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

>>> на крайний случай даже таскание c собой gcc не страшно.

Даже не знаю, как это назвать %)

А чем принципиально это отличается от таскания с собой jvm?

Принципиально? Ровно ничем. Есть кое-какие отличия в технических деталях, но ничего существенного. Отличное решение, правда-правда.

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

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

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

sbcl же компилятор

зачем тогда lisp, если планируется компиляция? фсе няшки lisp проявляются в интерпретации... если уж компиляция - пишите всё на голом c, будет профит и скорость

насчёт lisp посмотрите на gcl, вроде адекватный

и да, посмотрите на scheme алсо, есть mit-scheme

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

фсе няшки lisp проявляются в интерпретации...

И как давно так стало?

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

> фсе няшки lisp проявляются в интерпретации...

И как давно так стало?

сразу предупрежу: я не мега-лиспер и, возможно, ошибаюсь :)

насколько я понимаю что всегда так было, даже на пресловутом спутнике (или что там было) перегружали код в интерпретаторе ЕМНИП

shty ★★★★★ ()

А чем джава не устроила, если не секрет?

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