После почти шести лет разработки доступен (http://www.lua.org/news.html) релиз Lua 5.2 (http://www.lua.org/versions.html), быстрого и компактного скриптового языка программирования, получившего большое распространения в роли встраиваемого в других проекты языка сценариев (например, для определения конфигурации или для написания расширений). Lua комбинирует простой процедурный синтаксис с мощными возможностями описания данных через использование ассоциированных массивов и расширяемой семантики языка. В Lua используется динамическая типизация, языковые конструкции преобразуются в байткод, который выполняется поверх регистровой виртуальной машины c автоматическим сборщиком мусора. Сам интерпретатор оформлен в виде библиотеки, легко интегрируемой в проекты на языках Си и Си++. Код интерпретатора Lua написан на языке Си и распространяется под лицензией MIT.
Среди ключевых новшеств Lua 5.2 отмечается (http://www.lua.org/manual/5.2/manual.html) поддержка изменяемых pcall и мета-методов, н...URL: http://lua-list.2524044.n2.nabble.com/ANN-Lua-5-2-0-final-no...
Новость: http://www.opennet.me/opennews/art.shtml?num=32603
Ну и чем это отличается от java?
Не жрет память и не тормозит.
$ l /usr/lib/liblua.so.5.1.4
-rwxr-xr-x 1 root root 210231 Oct 29 2010 /usr/lib/liblua.so.5.1.4
> Не жрет память и не тормозит.Хорош уже самому тормозить, в 1997 году появился JIT, сейчас виртуальная машина Java реализована аппаратно в процессорах. АППАРАТНО В CPU! Не доходит?
это в каких? в ix86, x86_64, КР580?
в сим-картах например
В армах! Во всех современных смартфонах.
> это в каких? в ix86, x86_64, КР580?И что такое ix86? и x86_64? и при чем тут серия КР580 (x86 архитектура).
ix86 = Intel 386 или старше - 32-разрядный процессор настольных ПК
x86_64 = AMD64 или Intel EM64T - 64-разрядный --"--
>ix86 = Intel 386 или старше - 32-разрядный процессор настольных ПКПервое называется x86 и ведет свою родословную от 8086
>x86_64 = AMD64 или Intel EM64T - 64-разрядный --"--
Второе называется amd64 не путать c ia64, т.к. архитектура разная, хотя обе имеют эмуляцию x86, впрочем как и arm.
В общем я вижу "знатоки" собрались.
Называется КЕМ?x86 = i386 = 32-битный процессор = 32-разрядный процессор = ix86 = ещё сотня синонимов. Даже не упомню кто как его официально именует.
Для 64-разрядных знаю, потому что на моём веку появились:
- AMD64 - название в доках AMD
- Intel EM64T - название в доках Intel
- x86_64 - название на форумахЕсть и другие, менее используемые: "x86-64", "x64", "Intel64" (первая версия названия от Intel), и т.д.
По поводу нескольких названий всё просто: продвигать продукт, носящий название фирмы-конкурента, сложно.
С ia64 никто ничего и не путает. Как раз аббревиатура "ix86" появилась из "x86" чтобы чётко различать "ia" от "ix" на форумах, где грамотность обычно хромает и пропуски букв стали нормой.
Так что именно "знатоки", а не бакланы, как вы.
> x86 = i386 = 32-битный процессорХотел сообщить, что "знатоков" не зря в кавычки забрали (и что говорите про IA32), но нашлось http://www.intel.com/intelpress/chapter-scientific.pdf с утверждением "...the Intel® x86 architecture (also referred to as IA-32)"; спасибо.
Вам ли не знать что существуют версии документов... Тот же Intel не сразу пришёл к "EM64 T", какое-то время именуя технологию "Intel 64".
Стековые машины медлительны вне зависимости от того, виртуальные они или аппаратные.
Не хотел бы я пользоваться такими CPU.
JVM уже стало синонимом дырявости, уступая в этом только Adobe flash.
Из недавних новостей:
http://www.opennet.me/opennews/art.shtml?num=32541
> Обновление Java SE 6 Update 30 и Java SE 7 Update 2В новой версии отмечено около 680 исправлений.
Если вы пишите небольшие скрипты и прочие хелловорлды - то да.
> Ну и чем это отличается от java?Шустрой регистровой виртуальной машиной вместо тормознутой стековой, как у жабы, к примеру. И функциональным программированием вместо обьектно-ориентированного. И ориентированностью в первую очередь на встраивание в другие программы в качестве скриптов, а не на "энтерпрайз". Или ада-подобным синтаксисом вместо си-подобного. И нестрогой динамической типизацией вместо [почти] строгой статической. И вообще всем.
Ах да, и еще там массивы начинают отсчет с единицы, а не с нуля. Предмет более девяти тысяч холиваров.
> Или ада-подобным синтаксисом вместо си-подобногоПаскалеподобным, я бы сказал, но, тем не менее, довольно лаконичным. Имхо, с Адой не сравнишь, у нее синтаксис слишком монструозен
> Lua комбинирует простой процедурный синтаксисvs
> И функциональным программированиемОбъясните недобравшемуся -- так всё-таки процедурный или функциональным?
Стиль преобладает процедурный, но
f = function(a,b) -- функции — такие же переменные, как и всё остальное
c = a + b -- есть замыкания
return function(d) -- могут возвращать функции
return d(a,b,с) -- …и принимать их в качестве аргумента
end
end
как бы намекает.
http://ru.wikipedia.org/wiki/Мультипарадигмальный_язык_программирования
> http://ru.wikipedia.org/wiki/Мультипарадигмальный_язык_программированияДа на ruby-то не первый год блоками кидаюсь, что не делает язык функциональным.
Дано: скромная embedded система. Платформа 32-х разрядная, но не ARM и не x86. ОЗУ 32 Мб. Нужно немного скриптования. Выполнение скриптов задача хоть и нужная, но второстепенная и низкоприоритетная (в плане потребления ОЗУ и CPU).> Ну и чем это отличается от java?
Тем что вышеуказанное можно без особых проблем реализовать (да, собственно, уже реализовано) при помощи Lua или Squirrel, при помощи java - нет.
>Дано: скромная embedded система. Платформа 32-х разрядная, но не ARM и не x86. ОЗУ 32 Мб. Нужно немного скриптованияForth в руки и вперед.
Ну перепиши вебморду LuCI на forth, будет забавно посмотреть на это :)
А чего сложного то?
> А чего сложного то?Да, действительно.
Вот я начал переписывать...
переписываю...
переписываю...
переписываю...
переписал!
И совсем не сложно.
Реплику не понял.
В чем вы сомневаетесь?
Управление настройками роутера эта такая архисложная задача?
> Управление настройками роутера эта такая архисложная задача?Достаточно.
--
писавший морды
> Управление настройками роутера эта такая архисложная задача?напиши хотя бы один раз реализацию этой задачи. потом поговорим.
> Forth в руки и вперед.Только если уж очень "прижмет". Уж больно мне и остальной команде синтаксис не нравится.
В инете встречаются железные JVM для ПЛИС. Луа тоже есть? (сам ещё не искал)
> В инете встречаются железные JVM для ПЛИС.1) ПЛИС очень нишевые штуки.
2) От Java в системном программировании много гемора неизвестно ради чего.
3) Она там урезаная по максимуму.
>1) ПЛИС очень нишевые штуки.ПЛИС есть в любой промышленной железке страдающей наличием хоть какого-нибудь интеллекта.
>2) От Java в системном программировании много гемора неизвестно ради чего.
Как раз гемора то и нет. А в тех же ARM так вообще аппаратная поддержка Java.
>3) Она там урезаная по максимуму.
Аппаратная Java? Ну а какая она там должна быть?
> ПЛИС есть в любой промышленной железке страдающей наличием хоть какого-нибудь интеллекта.И во всех java? Кто то вас обманул.
>>2) От Java в системном программировании много гемора неизвестно ради чего.
> Как раз гемора то и нет.Вступление в системное программирование на java
"... прежде всего надо избегать создания объектов, так не предусмотренный запуск сборщика мусора с остановкой программы, может привести к непредсказуемым последствиям"
"... так же стоит избегать вызова библиотечных функций неявно создающих копии объектов по вышеописанным причинам. Примером такой функции является .sort()..."--
системный язык такой системный.
> А в тех же ARM так
> вообще аппаратная поддержка Java.Да Андроид и java ME на ARMе знамениты свей скоростью.
> Вступление в системное программирование на java
> "... прежде всего надо избегать создания объектов, так не предусмотренный запуск
> сборщика мусора с остановкой программы, может привести к непредсказуемым последствиям"Хорошо хоть пишут... если б ещё читали и не бывало http://www.opennet.me/openforum/vsluhforumID3/70660.html#46 :(
>> ПЛИС есть в любой промышленной железке страдающей наличием хоть какого-нибудь интеллекта.
> И во всех java? Кто то вас обманул.Не во всех. Не нужно утрировать.
>>>2) От Java в системном программировании много гемора неизвестно ради чего.
>> Как раз гемора то и нет.
> Вступление в системное программирование на java
> "... прежде всего надо избегать создания объектов, так не предусмотренный запуск сборщика
> мусора с остановкой программы, может привести к непредсказуемым последствиям"
> "... так же стоит избегать вызова библиотечных функций неявно создающих копии объектов
> по вышеописанным причинам. Примером такой функции является .sort()..."--
> системный язык такой системный.Еще бы ссылочку в "системное программирование на java" , а то просто текст не имеющий отношения к системному программированию и вырванный и контекста. Ложь.
>> А в тех же ARM так
>> вообще аппаратная поддержка Java.
> Да Андроид и java ME на ARMе знамениты свей скоростью.Удивлю? На армах вообще все современные сматрфоны.
Дамаю шансы найти железную реализацию Lua такие же как у JavaScript. Т.е. около 0.
С другой стороны, если ну очень хочется, от есть Luaj.
> Дано: скромная embedded система. Платформа 32-х разрядная, но не ARM и не
> x86. ОЗУ 32 Мб. Нужно немного скриптования. Выполнение скриптов задача хоть
> и нужная, но второстепенная и низкоприоритетная (в плане потребления ОЗУ и
> CPU).Вы про Playstation 2?
>> Дано: скромная embedded система. Платформа 32-х разрядная, но не ARM и не
>> x86. ОЗУ 32 Мб. Нужно немного скриптования. Выполнение скриптов задача хоть
>> и нужная, но второстепенная и низкоприоритетная (в плане потребления ОЗУ и
>> CPU).
> Вы про Playstation 2?Нет. Про некоторые свои разработки.
>поддержка оператора gotoОчень "ценная" фишка, актуальная так в 21 веке.
в системном программировании актуальная фишка, на ЛОРе пообсуждали
> в системном программировании актуальная фишка, на ЛОРе пообсуждалиПравда луа на системный ЯП никак не тянет. Скриптоязык он и есть скриптоязык.
Вы просто не знаете как скриптовые языки используются в системном программировании.
И вообще путаете задачи системного программирования с архитектурой и парадигмами применяемого для решения задач языка.
В определенных случаях оператор goto может упростить логику программы и сделать ее более понятной. И в 20 веке, и в 21 веке.
> В определенных случаях оператор goto может упростить логику программы и сделать ее
> более понятной. И в 20 веке, и в 21 веке.Да, да. Исследования 80-х показали что половина всех ошибок приходилась на goto. Добавление continue и break позволяет отказаться от него напрочь, за исключением ситуации выхода из глубоких циклов. После чего оператор goto нерекомендуется к использованию, ну кроме асма :).
while(A)
{
...
while(B)
{
...
while(C)
{
...
goto skip
...
}
...
}
...
}
skip:
> за исключением ситуации выхода из глубоких цикловВот именно в подобных случаях его изредка и встречаю. Только кроме циклов бывают ещё лихо закрученные условные операторы, когда после очередной проверки становится понятно, что всё плохо и надо хоть что-то на консоль вывалить, не беспокоясь уже о контексте...
Для этого рекомендуют блок try-catch-throw.try
{
...
if(непонятно что творится)throw 1;
...
}
catch(int a)
{
// сюда попадает если выполнился оператор throw
// или предыдущий код сгенерировал любую ошибку (деление на 0, обращение в NULL, ..)if(a==1){...}
...
}
> Для этого рекомендуют блок try-catch-throw.Это если он есть ;-)
> Для этого рекомендуют блок try-catch-throw.особенно в pure C, ага.
> Исследования 80-х показали что половина всех ошибок приходилась на goto.Исследования начала 21-го века показали, что 100% ошибок в программах приходятся на программистов.
Еще для конечных автоматов может быть полезен, при аккуратном использовании.
>>поддержка оператора goto
> Очень "ценная" фишка, актуальная так в 21 веке.ценная. и актуальная.
Реализация *интерпретатора* языка программирования?
не только, там сам язык заметно поменялся.
> Реализация *интерпретатора* языка программирования?Тогда уж и парсера тоже. Чего мелочиться-то?