LINUX.ORG.RU

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


0

0

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

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

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

★★

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

Он компилирует ровно тогда, когда это требуется. Ну хотие - называйте это помесью обычного компиллера + JIT для eval.
То есть с точки зрения производительности реального кода будет почти тоже, что и С. Но гибкость лиспа как была, так и остаётся.

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

> sbcl же компилятор, со всеми вытикающими от сюда

Ну и что? Будь он хоть быстрее асма, с кроссплатформенностью то у него полный швах. И это какбе всем давно известно. Не говоря уже о маргинальности самого лиспа. Где вы разработчиков найдете на многолетнюю поддержку? Перл - это ещё занятнее кандидат. Какое там нафиг удобство? Ублюдочный XS - это удобство?? Опять же поддержка кода... Пример багзиллы не учит? Насчёт gcc vs jvm - это вообще анекдот. «По объему в мегабайтах профита нет» - LOL!

Да, к луа прикручивают джит, ну чтож, посмотрим потом

Что значит прикручивают? Его давно уже используют, просто Google сейчас пилит 64-битную версию. И то, что они её скоро допилят, куда как более реально, чем то, что вы портируете sbcl на армы. Вообще lua-интерпретатор весьма шустрый даже без джита, не стоит от него так сразу отказываться даже не попробовав в качестве прототипа.

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

Не секрет. От самого языка будет использоваться лишь самая малость стандартной библиотеки. Гуй использовать не будет, он будет предоставляться С-частью. Не будет использоваться и всё остальное(даже стримы), чем так хороши Java с Нетом. То есть получается голая jvm+немножно явы, без особого использования её возможностей.
В этом смысле вариант с тасканием собранного gcc и использования С мало чем отличается, даже более интересен в силу более лёгкой интеграции.
Ну и да, конечно же личные предпочтения, то есть религия не позволяет:)

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

Если рассматривать Яву, то только в качестве 100% кода проекта. Да, тогда вариант. Но сабж не об этом.

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

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

Лиспов - море. Даже реализаций Common Lisp много, так что экстраполяция одного лиспа на все остальные не имеет под собой почвы. Common Lisp отлично совмещается с машинным компилятором, «няшки» не только не теряются, но ещё и значительно ускоряются.

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

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

Из всех реализация и так не особо популярного в продакшене языка вы написали самую мёртвую.

Уж лучше plt-scheme.

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

эта вакансия висит уже больше чем полгода, причем ее время от времени обновляют в поле «Требуемый опыт работы» =)

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

Меня больше всего поражает, как в эти стройные ряды вписались ASP.NET и RoR. )))

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

> От самого языка будет использоваться лишь самая малость

По-моему тот самый случай, где нужно думать о встраивании lua или tcl, а не о всякой эзотерике. Кстати, где у вас боттлнеки, продумали? И как так получается, что гуйня на С, а критические к производительности части планируется писать на искомом высокоуровневом языке? Подозреваю одно из двух: либо у вашего архитектора каша в голове, либо опасения по поводу производительности сильно преувеличены.

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

Common Lisp отлично совмещается с машинным компилятором, «няшки» не только не теряются, но ещё и значительно ускоряются.

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

и какие это «няшки» там остаются?

если же мы говорим про компиляцию в байт-код то тогда нужна виртуальная машина, а до виртуальной машины java, которая на некоторых приложениях догоняет С++ (а вовсе не С!), пока по скорости ещё никто не дополз даже близко

я чего-то не понимаю?

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

> я чего-то не понимаю?

Как минимум того, что в данном случае код виртуальной машины ничем не лучше нативного кода.

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

Уж лучше plt-scheme.

а на какие он платформы портирован?

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

а поподробнее?

Современные компиляторы Common Lisp преобразуют лисповый код в машинный код без потери динамических возможностей языка.

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

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

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

> я чего-то не понимаю?

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

эм, почему?

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

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

и мы не про то говорим, вроде :)

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

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

ба, скока спецов то понаехало!

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

> а поподробнее?

Современные компиляторы Common Lisp преобразуют лисповый код в машинный код без потери динамических возможностей языка.

оп! вот не знал, класс.

а в чём фишка, если не трудно? (в смысле за счёт чего это обеспечивается?)

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

насколько я помню

Забудь лучше, твои воспоминания ложные.

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

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

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

Он компилирует ровно тогда, когда это требуется. Ну хотие - называйте это помесью обычного компиллера + JIT для eval. То есть с точки зрения производительности реального кода будет почти тоже, что и С. Но гибкость лиспа как была, так и остаётся.

ну пусть будет так, в конце концов я даже не знаю какой именно проект обсуждается :)

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

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

а в чём фишка, если не трудно? (в смысле за счёт чего это обеспечивается?)

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

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

Сейчас это модно JIT зовётся. Компиляция по месту.

JIT - это компиляция портабельного байткода в машинный код целевой платформы. В случае с SBCL и подобными речь идёт о честном компиляторе: не входе исходник, на выходе маш.код. Ну и компилятор всегда в рантайме доступен.

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

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

Вовсе нет. Код с постоянным использованием упомянутых возможностей будет неэффективным, потому что оптимизация строится на том, что динамические возможности языка не используются или используются не сильно. Но в лиспе динамизм вычеркивается из рассмотрения на этапе компиляции (type propagation, о котором говорит mv).

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

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

а! так вот про что mv говорит :) ну лиспер, такой лиспер - прямо никогда не скажет :)

так скорость jit не всегда (!) можно назвать сравнимой с скоростью исполнения статически вкомпилированного кода, много циклов eval-compile, к примеру, могут насмерть убить производительность

и да, насколько я помню OCaml был таки быстрее SBCL... ога, вот сцылко

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

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

одно слово: скорость

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

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

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

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

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

Но в лиспе динамизм вычеркивается из рассмотрения на этапе компиляции (type propagation, о котором говорит mv).

хм, и чем он после того отличается от «такого же» кода на С? если же мы добавляем цикл eval-compile с перевешиванием указателей - то получаем снижение скорости работы

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

а! так вот про что mv говорит :) ну лиспер, такой лиспер - прямо никогда не скажет :)

Я не говорил про JIT. Более того, я говорил, что это не JIT.

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

> На С будет набор переносимых компонентов, которые в свою очередь будут экспортировать функции в высокоуровневую часть, нужные для работы(сеть, файлы, гуй, механизм подгрузки компонентов и тд)

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

Вы Tcl переизобретаете что ли? :)

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

И как у сбцл с трейсинг жит? Уже сделали? А то тут мужики http://lambda-the-ultimate.org/node/3851 считают, что трейсинг жит зарулил всех, а точнее комбинация статик+трейсинг, как мозилла сейчас делает.

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

> а! так вот про что mv говорит :) ну лиспер, такой лиспер - прямо никогда не скажет :)

Я не говорил про JIT. Более того, я говорил, что это не JIT.

значит «неправильный лиспер» - это кто-то другой :)

ЗЫ спасибо за содержательные ответы, как будет подходящий проект поковыряюсь с лиспами всякими, а то чего-то и правда запустил :)

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

> ну, наша беседа протекает в ключе эффективности и скорости выполнения

Разве? Вот по этой фразе:

насколько я помню компиляция в машинный код в динамических языках убивает всякие вкусности

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

Но в лиспе динамизм вычеркивается из рассмотрения на этапе компиляции (type propagation, о котором говорит mv).

хм, и чем он после того отличается от «такого же» кода на С?

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

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

> ну, наша беседа протекает в ключе эффективности и скорости выполнения

Разве? Вот по этой фразе:

насколько я помню компиляция в машинный код в динамических языках убивает всякие вкусности

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

mea culpa :) в голове жужжало, в посты не попало

> хм, и чем он после того отличается от «такого же» кода на С?

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

дык!

во-вторых, Лисп малость повыразительнее Си.

achtung, der holywar :) давайте замнём для ясности, ибо не на всех задачах - это истина :)

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

Вы Tcl переизобретаете что ли?

я так полагаю, что Tcl был признан незрелым и неуниверсальным, потому его решили, так сказать, обновить

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

> Это при таком раскладе будет основной затык, потому что данных будет много и обрабатываться они будут именно в «высокоуровневой» части

Что мешает опустить тяжелую обработку данных на нижний уровень? На верхнем останется только клей, и всё будет путём. Вы ж рассматриваете вариант писать всё на C, тогда уж основа на C + tcl как клей всяко лучше будет. В любом случае прототипировать и тестировать это всё нужно на чём то, уж точно не на C :)

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

а если выбрасывать это - то накукуй вообще лисп, вот что я пытаюсь понять

Функция + в Common Lisp принимает на вход любое количество аргументов типа «число» (целые разной разрядности, с плавающей точкой, натуральные дроби, etc). Все эти аргументы нужно правильно привести к общему знаменателю и сложить.

Рассмотрим код:

(+ 1 2)
Что компилятор тут видит?

1. Два аргумента. Соответственно, проверять количество переданных аргументов в рантайме не имеет смысла.

2. Аргументы целочисленные, у первого тип (integer 0 1), у второго (integer 0 2), т.е. значения занимают 1 и 2 бита соответственно. Такие типы гарантированно вмещаются в ту часть регистра, которую может занимать значение в типе FIXNUM (наиболее эффективный целочисленный тип по-стандарту). Можно использовать машинное сложение.

3. Результат операции будет максимум типа (integer 0 3). Эту информацию можно использовать в дальнейшем (via type propagation).

4. Да вообще складываются константы! Нефиг generic-+ напрягать, когда и так в compile-time ясно, что можно всю форму выкинуть и вместо неё вставить 3.

Таким образом, компилятор без потери динамичности языка в программе выполнил оптимизацию.

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

Что мешает опустить тяжелую обработку данных на нижний уровень? На верхнем останется только клей, и всё будет путём.

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

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

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

gcl

свали, пожалуйста, подальше, и больше не позорься

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

А что если

(define (my-sum x y)
  (+ x y 1))
как оно откомпилируется? С учётом того, что код
(set! + -)
(my-sum 3 4)
будет давать -2.

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

>>В общем задача на много времени вперёд(несколько лет как минимум), поэтому языки типо JS, lua и прочего - отметаются.

Lua и js не названы незрелыми, у них со скоростью проблемы


я читать разучился?
и да, какие у Lua проблемы со скоростью?

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

как оно откомпилируется?

В SBCL оно не откомпилируется =)

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

Чуть не поперхнулся. Какой город?

Просто обычно от «от 1690 USD» что-то в стиле «С++ Senior», невелика зарплата для таких знаний.

Пример, предлагалась работа JavaFX Senior - 25-40 USD per hour

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

Правда это был фриланс и проект горел. А так такому спецу как в сабже нужно как минимум 2000-2500

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

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

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

> А так такому спецу как в сабже нужно как минимум 2000-2500

Я думаю, что таких спецов, как в сабже, просто не бывает :) А если и бывают, то стоят они гораздо дороже.

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