LINUX.ORG.RU

Выход mocl

 , ,


7

8

mocl — набор инструментов для разработки на Common Lisp под мобильные платформы iOS и Android. По заверениям разработчиков получаемый код (используется LLVM) по производительности значительно превосходит аналогичный на Java/Dalvik.

В основе mocl лежит идея, заключающаяся в том, что логика приложения должна быть полностью описана на Лиспе, а пользовательский интерфейс — быть «родным» для платформы. Авторы проводят аналогию с Вэбом, когда логика серверного приложения описана на одном языке (например, на Лиспе), а представление — на другом (HTML + JavaScript).

Цена лицензии варьируется от $1299 для серьёзных компаний до $199 для индивидуальных разработчиков. Также предусмотрена «Source code license» для особых энтузиастов, доступ к которой, по-видимому, дают после обращения в службу поддержки.

Пример приложения на Github.

>>> Подробности

★★★★★

Проверено: mono ()
Последнее исправление: Dendy (всего исправлений: 4)

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

Так звучит более правдоподобно (хотя всё равно неизвестно, правда ли).

Не существует примеров подтверждающих обратное. Появятся - поговорим.

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

Всякие def-что-нибудь, раскрывающиеся в defun или defclass --- это же азбука лиспового макростроения.

Это как раз подтверждает то что я говорю.

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

Приличные компиляторы статически типизированных языков - начало 70-х, приличный JIT для динамического языка - начало 90-х.

Приличные лампы тоже появились сильно раньше приличных транзисторов

Потому что были проще. Так же, как статический компилятор проще динамического JIT.

Что ж теперь на ламповых компьютерах сидеть прикажешь?

Если ты не знаешь - статически типизированные языки развиваются и по сегодняшний день (в отличие от CL, кстати).

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

Для начала хотелось бы знать, возможно ли это вообще;

Вот-вот. Я думаю, что возможно - но поведение будет другим. Т.е. это будет уже не питон, а нечто с его синтаксисом.

потом - чего это будет стоить в реализации и использовании.

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

Кстати, попытки были.

Ждем полноценных реализаций, а не попыток. Пока говорить не о чем.

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

Не существует примеров подтверждающих обратное

Статически типизированных языков с макросистемами не существуют? Okay.

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

Ждем полноценных реализаций, а не попыток

Жди-жди.

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

Qi?

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

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

Какие?

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

статический компилятор вещь сложная.

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

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

Можно для разных типов генерировать различный AST, вызывать разичные оптимизированныё структуры и т.д.

Для этого не нужна статическая типизация. Анализируется внешним чекером, в рантайме перед jit-ированием.

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

статически типизированные языки развиваются

Ога. Последняя редакция С++ почти догнала лисп двадцатилетней давности.

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

Ничего не могу сказать, не интересовался. Но в качестве proof of concept «статичести типизированный лисп бывает» сгодится.

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

статически типизированные языки развиваются

Ога. Последняя редакция С++

Си++? Бугага.

почти догнала лисп двадцатилетней давности.

Да неужели?!!11 Слушай, а в чем? Какие фишки божественного Лиспа появились в Си++11?

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

Вообще шумит именно то что высокоуровневые концепции типа тех же классов декларятся очень низкоуровненым структурным синтаксисом. Как в XML.

Убери из лиспа скобки - получишь питон. xml, sql, html - это все частные случае s-expression :) В случае xml не совсем удачные.

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

Если ты не знаешь - статически типизированные языки развиваются и по сегодняшний день (в отличие от CL, кстати).

Да ну что ты. Нынешнее развитие статически типизированных мейнстримных языков, это лалка. Если, например, взять C++, то все новые фичи — старые фичи из ФЯП (type inference, lambda) и Lisp (constexpr). До уровня CL по фичам C++ ещё лет 100 такими темпами :) CL можно ещё век не наворачивать — воз и ныне там будет. А добавляемую синтаксическую пудру можно за вечерок с друзьями под пиво в пару сотен строк написать на CL. Такие дела.

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

Си++?

Есть такой язык. Погугли.

Какие фишки божественного Лиспа появились в Си++11?

Лябды, конечно же. + вывод типов доделали, for стал похож на mapcar местами, шаблоны слегка улучшили etc.

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

Какие фишки божественного Лиспа появились в Си++11?

Лябды

Странно, что ты не сказал «Лисп 50-летней давности». Смысла столько же, но звучит эффектнее.

+ вывод типов доделали

шаблоны слегка улучшили

Да, вывод типов и шаблоны в лиспе - это просто пушка.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от harm

Лябды, конечно же. + вывод типов доделали, for стал похож на mapcar местами, шаблоны слегка улучшили etc.

Ну да. А ещё там чуток осталось. Макросы, сигнальный протокол, да и CLOS сделать. Делов-то :) Лет 100 и С++ на коне (хотя сдохнет скорее).

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

Да ладно, можно же считать, что динамика - это статика, но у всех объектов один и тот же тип.

Не, нельзя. В строгой динамической типизации мы не сможешь сложить числа со строками. Типы имеются, но до определенного момента неизвестны.

«Остапа понесло» (ц)

Статическая типизация - преждевременная оптимизация для прототипа, и следовательно корень всех зол :) При постоянно меняющихся требованиях, а с ними и архитектуре - приложение всегда остается «прототипом». Консервируются только отдельные ее части. И либо переписываются на Си всякая числодробня, либо (желательно) смазывается декларацией типов.

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

Но в качестве proof of concept «статичести типизированный лисп бывает» сгодится.

А это не так сложно, я просил пример статически типизированных лисп-макросов, а не лиспа.

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

можно же считать, что динамика - это статика, но у всех объектов один и тот же тип.

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

Не противоречит.

Статическая типизация - преждевременная оптимизация для прототипа, и следовательно корень всех зол :)

Статическая типизация - это средство полностью исключить определенный класс ошибок и, следовательно, абсолютное благо.

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

Даже синтаксическим, посмотри на:

по такой логике любую последовательность символов можно назвать «s-expression»

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

for стал похож на mapcar местами

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

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

по такой логике любую последовательность символов можно назвать «s-expression»

Ну да. Почти так и есть.

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

Странно, что ты не сказал

Это было бы неправдой. А врать мне мама запрещает.

Да, вывод типов и шаблоны в лиспе - это просто пушка.

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

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

а SQL то каким боком?

Всё, что при желании можно записать в S-выражениях - Лисп :) И неважно, что SQL записывается в такой форме лишь при большом желании.

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

Ну да. А ещё там чуток осталось.

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

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

Не противоречит.

Если не противоречит, то почему ты не можешь сложить объекты одного типа? Это не объекты одного типа, а именно что «неизвестно».

Статическая типизация - это средство полностью исключить определенный класс ошибок и, следовательно, абсолютное благо.

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

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

Статическая типизация - это средство полностью исключить определенный класс ошибок и, следовательно, абсолютное благо.

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

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

по такой логике любую последовательность символов можно назвать «s-expression»

Нет. Но sql можно к s-expression привести.

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

fail, там макроподстановка идет до тайпчека.

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

Статическая типизация - это средство полностью исключить определенный класс ошибок и, следовательно, абсолютное благо.

Т.е. если у чего-то есть положительная сторона, значит оно является абсолютным благом? Амиго, ты заработался.

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

Это было бы неправдой. А врать мне мама запрещает.

Лямбды были в Lisp 1.5 - как раз 50 лет назад, так что мама была бы не против.

Да, вывод типов и шаблоны в лиспе - это просто пушка.

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

Я и не спорю, а информации к размышлению в «словах опонента» нет.

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

Амиго, ты заработался.

Мобилизуй свое ЧЮ и прочитай фразу, на которую я отвечал.

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

Да ну нахрен.

Да и действительно. Кого я пытаюсь обмануть :)

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

Да, вывод типов и шаблоны в лиспе - это просто пушка.

Действительно, вывод типов и шаблоны это не Lisp'овская затея, из-за динамической природы. Но и не крестовая подавно ;) Ada и ML. Нового в крестах 0.

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

О процессе разработке, о том, чем был Python, чем стал - кстати, яркий пример, как открытость разработки делает из овна конфетку.

В php тоже появились и классы и прочей фигни много. Он этого он не стал жабой.

Для статики перестали писать тесты? Или их пишут меньше?

При чем тут тесты? Я говорю что написать язычек на коленке интерпретируемый можно за день. А введи туда хоть простейшую типизацию - и это уже значительно возросшая сложность. Потому всякие питоны и руби начинают заниматься оптимизациями виртуальных машин шоб хоть как-то не тормозить - и солжность возрастает уже тут. Но не могут же они «а теперь стать статическими» - это уже принципиально другой язык.

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

f(i:Int) = i^2
f(s:String) = s + s

правда?

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

Я сейчас пишу на эрланге. Как для динамического языка мне что-то уж сильно много типов руками надо указывать или проверять.

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

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

Ненужна это мантра такая? ЛУчше делать руками то что делать руками не надо?

99% серверов приложений не вне унылого интерпрайза - на динамике.

Эти влажные фантазии не подтверждаются даже tiobe.

Потенциально, да - мы все ждем крутого,

facepalm.rb

Какая глупость, есть веб (перспективная и возможно самая социально значимая сфера в ИТ), но нет инструментов, кроме пхп, перла и cgi, чтобы разрабатывать можно были без боли

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

Есть бизнес процесс и динамичное изменение требований к системе, нам собирать тупо некогда.

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

Ну да, лучше всего было бы не выпустить фейсбук

Это все тебе задвигальщики хипстерской идеи - продавцы книг как стать милионером голову вскружили.

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

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

Специфичность стиля и разница алгоритмов - это не одно и то же, в задачах типа этой где надо развлекаться с колллекциями.

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

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

Унылость реализации рубиновых клиентов к вебсервисам типа амазоновых или ебеевых с тобой не согласна.

1) Мне не приходится декларировать типы

Открой любую эрланговўю прогу и удивись.

2) Не приходится собирать и компилировать

Ну да - десяток файлов в проекте - можно не заморачиваться.

3) Не приходится бороться с системой типов

Только страдать от ее отсутствия.

4) Не приходится городить костыли для создания систем с динамичной жизнью

Obvious fix как показывает руби: 4) Не создавать системы с динамичной жизнью

Там пишут бойлерплейт. Извини но вот такое даже в простых статических языках типа жабы генерируют: https://github.com/codyfauser/ebay

5) Еще мне не приходится отказываться от макросов

scalamacros.org

И хуярить интерфейсы на каждый чих.

угу - structural types не существуют, structural types не существуют...

Динтипизация - это, как я уже сказал, такие соглашения по интерфейсам в документации к проекту.

Давайте скажем что бага это фича...

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

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

Ну там вполне себе табличка. Каких строчек я не заметил конкретно?

Понимаю, ты привык так думать, но как-бы девяностые прошли, пора привыкать к новому.

А shootout все такой же.

Если не заботиться о скорости --- студенческая курсовая.

Ага - на уровне паскаля. Добавь сюда type inference, higher kinded types, effect systems и прочее - и обана.

Не зря хороших оптимизирующих компиляторов с и лиспа примерно одинаковое количество: единицы штук.

У Си очень примитивная типизация.

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

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

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