ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Понедельник
23 декабря
907638 Топик полностью
Связанные сообщения
TypingCppScriptingMultidimensionalMetaprogramming
Мнится мне, что кто-то уже записывал такие мысли на песках Сахары...2024-06-19
[Мелкие встраиваемые скриптовые и компилируемые языки.] Сводный топик. Лучше пройтись поиском - почти все языки не раз у ...2024-02-26
[Q3VM] A lightweight (single file: vm.c) embeddable interpreter/Virtual Machine (VM) for compiled bytecode files (.qvm) based on...2024-02-22
[mJS] Restricted JavaScript engine. Серьезная штука!2023-02-18
[EmbedVM] is a small embeddable virtual machine for microcontrollers with a C-like language frontend2023-02-18
[Lua RTOS] - сбыча мечт?2022-11-10
Вы просто не умеете его готовить. Я бы мог бесконечно показывать примеры, но это непробиваемо. Сразу авторитетно докажут, что у ...2022-09-30
micropython был?2022-09-23
Сравнение эффективности, в т.ч. скриптовых языков. 2017 г.2022-09-22
[Squirrel] встраиваемый язык программирования, конкурент Lua. Сводный системный.2022-07-02
Embedded Template Library (iar arm 9.20.4)2022-05-18
Может кому пригодится: скрипт, который к себе цепляет и разворачивает tar-архив. При желании можно запустить скрипт из этого сам...2021-12-10
Наброшу.2021-12-06
Наверное не совсем мелкий, но для большого контроллера может подойти, старый, лет 20 уже: S-Lang. Встраивался, как я помню, в Sl...2020-11-04
Раз сводный топик, то ещё раз Squirrel, который вполне может конкурировать с Lua.2020-11-04
Самсунговский JerryScript: легковесная реализация JavaScript для IoT. Он правда не совсем мелкий, но зато относительно вполне се...2020-11-04
В поисках идей для GUI наткнулся на ZOE. Он сделан на языке REBOL. Не пойму - он встраиваемый, скриптовый?2020-11-04
Lua - странно, что до сих пор не упомянут. можно перенести.2020-11-03
Опишу задачи.2020-10-31
Процитирую сам себя: "Разработка ПО большого объёма на языках с динамической типизацией, как правило затруднена, но в целом скор...2020-10-30
В C++ доступна вся C-библиотека. Когда C++ сам себе разумеется нет, а как ты себе представляешь? Можешь написать свою реализацию...2020-09-23
Ты хочешь static_if, которого в C++ в чистом виде нет. constexpr if это совсем не то, т.к. он неизбежно будет компилиров...2020-07-02
В общем случае может быть 2-3 подхода перечисленных ниже. В базе всегда SFINAE -- шаблон откидывается и просматриваются следующи...2020-07-02
Надо понимать, что класс -- это не структура. Применительно к C++ мне больше нравится слово тип. Тип -- это сущность существующа...2020-04-26
Тебе нужен встраиваемый интерпретатор способный работать в REPL-режиме. Я уже ранее давал тут ссылку на partcl, lil, picol и ...2020-03-25
Я говорю про другую типизацию. Не про int или long, и даже не про int или char*. Программа на ООП-языке существует в рамкой неко...2019-12-19
C#, Java и тем более Javascript -- это совсем другой код, нежели C++. На порядок менее оптимальный, если конечно задача не своди...2019-12-19
С языком очень даже связано. Компилирующие языки со статической типизацией (C++, C#, Java, C, Pascal) пропускают гораздо меньше ...2019-12-17
Не совсем. C++ -- это уход в сторону _типизированных_ ЯВУ, а Java или C# -- подвижка в сторону "управляемого кода" и что наиболе...2019-11-03
Да конечно, ну вот расскажи, как оно работает -->2019-10-25
Мне какой-то куб для Renesas вспомнился, лет 6 тому назад. Они хвалились, что у них код компилится сразу, как его пишешь. В итог...2019-10-25
Увы, часто нет. Ардуины не просто так возникли. МК подросли и стали возможны другие подходы к разработке. Видно же что делается:...2019-03-03
Не соглашусь, во-первых я чётко подвёл к мысли, что возможны разные классификации, существование одних не запрещает другие. И ес...2019-03-03
[Язык Forth] сводный системный топик.2018-01-22
Угу, обсуждались, ещё вон PicoC был 2017-12-24
Для этого просто существуют разные языки! Смотри вторую ссылку: 2017-11-29
Утиная типизация - это оно? -> -->2017-11-28
Это не языки, а один язык - Tcl. А вот по-настоящему мелкий - это Pawn.2017-09-29
small version of Tcl -> подборка2017-09-29
LIL - Little Interpreted Language. Сильно упрощенный Tcl. ->2017-09-29
Picol упрощенный недоTcl -> home -->2017-09-29
Jim - компактный, но быстрый и фичастый интерпретатор TCL ->2017-09-29
Дополню, что успел наковырять. #интерпретаторы #скрипты2017-09-15
EvgenyCD! Смотри ссылку! Я понял, что это круче чем swig, например, в определённых обстоятельствах. Правда руки применять надо...2017-02-09
JIM - интерпретатор Tcl, заточенный под embedded приложения. -> Используется в том числе в этом WEB фреймворке -->. Очень ...2012-12-26
Это свойство практически любого языка с динамической типизацией. Здесь питон притянут за уши. Но это НЕГАТИВНОЕ свойство для бол...2010-01-13
fk0легенда (01.03.2019 01:34, просмотров: 1249) ответил General на Лично мне для php нужно, а лучше универсальное решение.
С этого стоило и начинать. С того, что язык скриптовый. И это уводит совсем в другую сторону, практически в параллельную вселенную. Для тех кому лень дальше читать: ActiveState Komodo. Начать следовало бы с дихтомии языков программирования. Или для начала: забыть всё то, что писалось в ширпотреб-литературе для студентов. Это всё ложь, матрица искусственного мировоззрения, розовые зелёные очки наконец. Программа не является последовательностью инструкций -- наверное это главный постулат, который бы следовало всегда помнить. Последовательностью инструкций, в лучшем случае, является производная программы, продукт работы компилятора, да и то на весьма ограниченном локальном участке, например в пределах функции. Во всех остальных случаях программа в совокупности с вычислительной машиной является скорей является гигантским конечным автоматом. Программа в чистом виде, без вычислительной машины -- набором логических правил. И на этот набор правил можно смотреть под разными углами и видеть разное. Можно видеть как из одних правил выводятся другие и так рекурсивно. Можно видеть таблицу или граф конечного автомата. Может даже пригрезиться последовательность инструкций. Можно видеть функции и их определения через другие функции, можно увидеть даже классы и отношения между ними... В соответствии с этими взглядами языки программирования делятся на разные классы: декларативные, императивные, функциональные, логическoго программирования, макропроцессоры... Но это лишь один способ деления и он не является всеобщим и отрицающим какие-либо другие способы деления. Есть и другое деление, очень важное: языки разделяются на динамически типизированные и языки с жёсткой типизацией. Некоторые, правда, занимают местами промежуточное положение. Разработка ПО большого объёма на языках с динамической типизацией, как правило затруднена, но в целом скорость разработки на таких языках может быть сильно выше (http://caxapa.ru/797984.html). Большой проект можно начинать прототипировать на типичном скриптовом языке, но со временем следует переписывать с применением ООП и желательно на строго типизированном языке типа Java, например. Ещё одним способом деления является, разделение на языки интерпретируемые и компилируемые. Границы здесь могут быть размыты, т.к. многие интерпретируемые языки сейчас имеют встроенный компилятор в байт-код или даже в машинный код. Но важным отличием интерпретатора может являться факт, что программа на интерпретируемом языке может сама генерировать программы на этом же языке, которые могут быть тут же проинтерпретированы. Это подводит нас к метапрограммированию. Ещё одним важным способом деления может являться наличие возможностей метапрограммирования. Это когда программист, вместо непосредственно написания программы на данном ему языке программирования, может на некотором другом, или этом же языке создавать программу, которая сгенерирует другую, нужную программисту программу. Процесс, понятно, может быть достаточно многоуровневый и в пределе рекурсивный. Многие интерпретируемые языки обладают способностью к метапрограммированию ввиду наличия функции "eval" или подобной. Но из сказанного выше никак не следует, что способностью к метапрограммированию обладают только интерпретируемые языки. Компилируемые языки тоже такой возможностью могут обладать. Либо посредством применения макропроцессора, как это сделано в языке C (и надо помнить, что существуют нестандартные сторонние макропроцессоры с существенно большими возможностями, в частности допускающие рекурсию и являющие тьюринг-полными языками программирования). Либо, как в случае с C++, метапрограммирование может являться частью самого языка (здесь надо сделать отступление, см. ниже). Ещё могут разделять языки на скриптовые и прочие. Скриптовые языки обычно являются интерпретируемыми, впрочем никто не запрещает их компилировать. Обычно скриптовый язык предполагает возможность интерактивной работы и восприятия программы как текста, применительно к которому могут использоваться практики метапрограммирования. Наверное следует ввести ещё один способ деления языков на две группы: это способность к модификации самого языка, его интерпретатора если это интерпретируемый/скриптовый язык, или компилятора при компиляции, средствами самого языка или его макропроцессора. В принципе опять же это применимо и к компилируемым языкам, например к lisp. Например язык C такими возможностями не обладает, C++ очень скромными, а многие скриптовые языки, наоборот, очень широкими. Интерпретатор в процессе исполнения программы может запросто удалить из языка ряд ключевых слов, ввести новые, поменять логику работы операторов... Это очень важная особенность. Практически программа после начала интерпретации может модифицировать интерпретатор до уровня, когда он станет способным исполнять программу на некотором другом уже языке, не на том, на котором он исполнял изначально. Например, широкими возможностями обладает Tcl, в котором практически нет понятия "ключевых слов", в какой-то мере Perl, не знаю про Python или PHP, но очевидно в какой-то мере тот и другой такими возможностями обладают. Что из сказанного следует. Что PHP является типичным скриптовым, интерпретируемым (компиляция здесь лишь способ оптимизации) языком программирования, обладающий богатыми средствами метапрограммирования и способным в какой-то мере изменять окружение/интерпретатор по мере выполнения программы. У этого утверждения есть серьёзное последствие. Создание IDЕ, в том виде, как привыкли для Pascal, C, Java и даже C++ -- скорей невозможно. Равно как и невозможен разбор/анализ программы со стороны IDE. Программа не будет понятна пока она не запустится, в общем случае. В частных, конечно, возможны какие-то ухищрения и упрощения создающие видимость правильно работы IDE, но повторюсь, в общем случае такую IDE практически невозможно создать. Либо можно сильно ограничить программиста и превратить скриптовый язык в подобие паскаля, например. И тогда программа сразу станет легко анализируемой. Ещё одним препятствием к созданию типичной IDE для скриптовых языков является отладчик. Пошаговая отладка, в привычном для Pascal/C программистов скорей невозможна. Верней не так. Пошаговое исполнение-то в какой-то мере возможно (оно, скорей, ограничено по техническим причинам: обычно нет возможности поставить точку останова на строку, но зато есть другие странные возможности, например, слежение за изменениями переменных, переход в режим интерпретатора и ручное исполнение кода...), но само восприятие подобной программы должно быть несколько иным. Как относиться к тому факту, что одна функция может поменять текст другой функции, или написать третью функцию, переименовать четвёртую, удалить пятую, да и с переменными поступить примерно так же? Ибо функция не больше, ни меньше, а что-то вроде переменной хранящей текст. Пусть и параллельно хранится скомпилированный машинный код, это лишь временная сущность перегенерируемая при каждом изменении текста функции. Развитых IDE для таких языков, в том виде как это есть для Pascal/C нет, есть отладчики, но они специфические для Pascal/C программиста. Если отвечать на изначально заданный вопрос, то лидером в создании хоть каких-то IDE для скриптовых языков является фирма ActiveState. Komodo IDE работает с основными (Tcl, Python, Perl, PHP) скриптовыми языками. Собственно и сами интерпретаторы данной фирмы вполне осмысленны, если нужно установить на Windwos -- в дистрибутиве обычно широкий набор библиотек, документация, и всё работает из коробки. На Linux смысла особого нет, но тоже можно установить не версии из дистрибутива, а версии от ActiveState. Выше а говорил, про метапрограммирование в C++. Это отдельная очень интересная история. В языке C++ в последние 15 лет произошли очень серьёзные и интересные изменение и практически сейчас рождается новый язык с очень интересными свойствами и не имеющий в общем-то аналогов. Многие может неправильно воспринимают C++, прочитав в какой-то книге 90-х годов, что это мол объектно-ориентированный язык. Нет! Это лишь одна из парадигм программирования реализуемая в этом языке, и это была главенствующая парадигма в C++ в момент его создания, в 90-х годах. Но сейчас всё не так. C++ давно сильно изменился, возможности ООП конечно остались, но они уже не являются главным свойстом языке. Главное свойство современного C++ -- метапрограммирование. Причём метапрограмирование на несколько другом уровне, может быть на более высоком, чем позволяют современные скриптовые языки. Эту возможность C++ получил, что удивительно, практически случайно. Ещё на ранних этапах разработки потребовались обощённые функции, их тяжело/невозможно было сделать средствами C-препроцессора и появились шаблоны. Они не создавались как средство программирования для программирования, даже по названию ясно что суть шаблона просто подставить некоторые значения "по шаблону". Именно то что нужно для обобщённой функции. Кстати язык C, в стандарте C11, пошёл именно по этому пути создав именно обощённые функции. Когда подразумевается подстановка, а не когда поведение программы может быть каким угодно разным в зависимости от типа. Вторым важным свойством C++ является типизация. Нет, тип это не способ представления данных в машинной памяти, не их размер. Тип это нечто другое. Просто опять же само понятие типа произошло от разных машинных типов данных, от способа представления классов или структур. Но настоящая суть типа в другом. Я думаю, понятие типа или класса как формы представления данных в памяти, как сущности которая может быть воплощена (инстанцирована в памяти), и понятие типа как некой высшей невоплощаемой сущности имеющей смысл в момент компиляции будет рано или поздно разделено. Важно что невоплощаемый тип может обладать разными свойствами и другими типами, управляющими работой компилятора и в конечном счёте генерацией кода. Фактически типы -- это отдельное пространство имён существующее только в компиляторе и в его рамках возможно программирование программ. Причём не в терминах набора символов, как это осуществляется в скриптовых языках, а в терминах тех понятий которыми уже изначально оперирует компилятор. Это большой шаг вперёд, и надо сказать современная C++ библиотека, например в последнее время (последние лет 10) тоже широко шагнула вперёд. Надо заметить и constepxr функции тоже большой шаг, но немного в другом направлении. Если метапрограммирование на уровне типов оперирует понятиями самого языка программирования, то constexpr функции оперируют понятием данных которыми же потом может оперировать уже запущенная программа, соответственно в ряде случаев возможно произвести какие-то операции над данными ещё в момент компиляции, а не в рантайме. И самое главное, в отличии от скриптовых языков C++ всё ещё возможно разобрать в рамках IDE. Сложно, много проблем, сложность парсера сопоставима с компилятором, скорей даже просто нужно использовать для этого компилятор. Но всё ещё возможно. А скриптовые языки понять наболюдением со стороны невозможно, только через исполнение.
[ZX]