Состоялся релиз mruby 3.0, встраиваемого интерпретатора динамического объектно-ориентированного языка программирования Ruby. Mruby обеспечивает совместимость синтаксиса на уровне Ruby 1.9, но также поддерживает отдельные возможности из более новых версий. Интерпретатор отличается низким потреблением памяти и возможностью встраивания в другие приложения. Кроме того, поддерживается компиляция Ruby-программ в байткод при помощи развиваемого проектом компилятора "mrbc". Код mruby распространяется под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54712
> для правостороннего присваивания значений.За этим есть реальный логический смысл или просто "когда лень Crtl+X сделать"?
причём здесь логический смысл? просто такой синтаксис оператора
В какой-то степени
Например когда тебе надо из цепочки методов сделать присваивание
a="hello"
a.upcase.reverse => b
конечно можно написать и так
b = a.upcase.reversНо если цепочка методов очень длинная то почему бы не использовать такой синтаксис.
лично мне это для однострочников нравиться
так и скажи - для обфускации однострочников ))
Так и скажи, что просто хейтишь то, что для тебя необычно
Это тестовая фича новый рубей, кажется. Зачем оно надо, впрочем, непонятно, да.
Конвейер же....
> За этим есть реальный логический смыслЛогического смысла нет. Но почему обязательно смысл должен быть логическим? Ты никогда не задумывался о том, что задумка программиста и код, которым он реализует задумку -- это разные вещи? Так же, как допустим, мысль у тебя в голове, и слова которыми ты мысль выражаешь -- это разные вещи. Когда ты читаешь код, ты видишь код, но чтобы с кодом осмысленно работать, нужно видеть за кодом задумку, которая его породила. Так же как, участвуя в разговоре, надо работать не со словами, а со смыслом, которые эти слова пытаются передать.
Но теперь прикинь, заглядываешь ты код и видишь:
switch(o->type) {
// и тут пара сотня case'ов
}С точки зрения синтаксиса -- это просто switch, с точки зрения процессора -- это jmp-table. Но с точки зрения задумки, очевидно, что это наколенный ООП, с динамическим полиморфизмом организованным посредством enum'а и switch'а по нему. Тот же ООП можно было бы реализовать при помощи virtual метода в o. Ту же самую задумку, можно реализовать другим способом. И в то же время, используя тот же самый способ (switch) можно реализовать совершенно другую задумку, которая никакого отношения к ООП не имеет.
Вдумайся в это, есть пространство идей, есть множество всех возможных кусков кода. Твоя голова сопоставляет идеям куски кода, и кускам кода идеи, то есть реализует, говоря математическим языком, отображение одного в другое. Если тебе хочется не просто теоретически эту мысль уловить, а практически посмотреть, то я б рекомендовал покодить на ассемблере, и почитать код на ассемблере. Ты увидишь, как твоя голова, со временем, начнёт выдирать из списка инструкций некоторые, и такая "о, push ebp/mov ebp esp -- это создание стекового фрейма". Или mov [ebp+4], 5: это же в переменную на стеке кладётся 5. То есть, твоя голова начнёт сложным образом дешифровывать ассемблерный код, и видеть идеи за кодом. Со временем она начнёт видеть всё более и более сложные паттерны и опознавать их.
Но это иногда всё равно даётся крайне сложно. Зная это, опытные программисты пишут код так, чтобы из него легко можно было бы вывести идею, которая код породила. Когда им это не удаётся, они дополняют код комментариями. Но даже комментарии не всегда решают проблему -- они многословны, неформализованны, имеют тенденцию со временем расходится с кодом по сути, потому что компилятор их игнорирует, и вообще комменты -- это сакс, это костыль, подпирающий ущербность языка программирования.
В большинстве случаев же, опытным программистам удаётся писать понятный код. Как они этого достигают? А это сложная тема, которая, я подозреваю, граничит с психолингвистикой, с тем как человеческие мозги обрабатывают речь. Но как бы там ни было, напрашивается рождение идеи напихивания в язык много разных способов написать один и тот же код, с тем чтобы выбором способа можно было бы намекать на идею, породившую этот код. В этом направлении развития языков программирования сильно отличился Ларри Уолл, который запилил Perl. Что любопытно, Ларри ведь по образованию лингвист, и он получал образование в надежде найти язык без письменности и запилить к нему письменность. С этим не сложилось, поэтому он запилил Perl. Но я отвлёкся. Так вот, Ларри запиливал Perl с явно высказанной идеей о том, что в Perl'е всё что угодно может быть сделано несколькими способами. И слова о выразительности языка тоже звучали. Я не слышал правда, чтобы он говорил о той выразительности, к которой я выше подводил, но подозреваю, что речь именно о ней.
Так вот ruby можно рассматривать, как дальнейшие исследования в том же направлении, просто в другом синтаксисе, и разработчики, мне кажется, более конкретные идеи имеют в виду, когда дают специальные способы для их записи.
Насколько этот подход хорош или плох -- сложно сказать. Я не настолько знаю ruby, чтобы оценить работает ли это в нём, но в perl'е это не сработало так, потому что программисты на perl не думали о том, как они потом будут читать свой код, и лепили его первым пришедшим на ум способом, в результате чего, читаемость программ не повышалась, а снижалась.
В противовес Ларри, Гвидо ван Россум -- математик, и в Python акцент делался на читаемости: принцип «явное лучше неявного».
«явное лучше неявного» далеко не всегда улучшает читаемость. Часто наоборот, замусоривает код и читаемость ухудшается. В С все очень явно описывается, я бы не сказал, что код легко читать. Логика не видна в куче бойлерплейта.
Фига тя прет
Не прочитал, но интересно!
> программисты на perl не думали о том, как они потом будут читать свой код, и лепили его первым пришедшим на ум способом,А что, прогеры руби чем-то лучше?
> Со временем она начнёт видеть всё более и более сложные паттерны и опознавать их.
Ну есть конечно люди которые по 4к символов в минуту считывают и интерпретируют, но как увидеть паттерн если его части разделены кусками кода большими чем лезет в экран, собственно для этого придумали языки верхнего уровня, чтобы логику отдельно вытащить, но не везде это зашло, а надо ли везде?
> ...Но с точки зрения задумки, очевидно, что это наколенный ООП
Вот не надо тут красок, всегда считал, что код, чем тупее тем лучше, весь этот синтаксический сахар только усложняет чтение, идеально тупому коду комменты не нужны, там и так все ясно, потому что конструкции типа присвоения и if-else ветвление и больше ничего.
> психолингвистикой
Вам блин шашечки или ехать, вы еще стихи насочиняйте на с++, в математике вообщето доказывается, что а + б = б + а, а попытки "дать возможность по иному", от лукавого, так как дополнительный вектор атаки, так как читать сложнее, а как там компилятор решит с оптимизировать вообще неизвестно, почитайте нормальных произведений на подходящих языках, и не надо сочинять байт-сонаты пряча максимум операций в минимум байт, для любителей извращений есть брейфак, а на работу латекс лучше не одевать.
>> программисты на perl не думали о том, как они потом будут читать свой код, и лепили его первым пришедшим на ум способом,
> А что, прогеры руби чем-то лучше?Я же написал выше: не знаю. Про перловых я знаю, про рубистов -- нет.
>> Со временем она начнёт видеть всё более и более сложные паттерны и опознавать их.
> Ну есть конечно люди которые по 4к символов в минуту считывают и
> интерпретируют, но как увидеть паттерн если его части разделены кусками кода
> большими чем лезет в экран, собственно для этого придумали языки верхнего
> уровня, чтобы логику отдельно вытащить, но не везде это зашло, а
> надо ли везде?Я использовал слово паттерн с тем чтобы намекнуть на паттерны программирования, тут ты правильно угадал. Но имел в виду я всё же несколько более широкое явление. Скажем в C++ довольно распространено префиксовать переменные-члены класса, дабы в коде было бы сразу ясно, что это за переменная _size и откуда она взялась. Или приведённый выше пример switch(o->type).
>> ...Но с точки зрения задумки, очевидно, что это наколенный ООП
> Вот не надо тут красок, всегда считал, что код, чем тупее тем
> лучше, весь этот синтаксический сахар только усложняет чтение, идеально тупому коду
> комменты не нужны, там и так все ясно, потому что конструкции
> типа присвоения и if-else ветвление и больше ничего.Да. Точно. Я в 18 лет, считал, что языки уровнем выше ассемблера для слабых духом.
>> психолингвистикой
> Вам блин шашечки или ехать, вы еще стихи насочиняйте на с++, в
> математике вообщето доказывается, что а + б = б + а,
> а попытки "дать возможность по иному", от лукавого, так как дополнительный
> вектор атаки, так как читать сложнееНеа. Проще читать на русском, чем на языке программирования, так? И пространство концепций, которое можно высказать, больше. Язык программирования более формален, из-за этого на нём сложнее выражать мысль, а часто сложнее понимать. Но зато выраженная мысль более формализована, доведена до математической точности.
Вообще я бы рекомендовал очень осторожно относиться к словам "проще"/"сложнее" -- как-то так выходит, что они используются очень противоречиво и многозначно, особенно в применении к языкам программирования.
> Неа. Проще читать на русскомO_o
Серьезно?
Да вот фига, давай на русский переведи логику какой-нибудь схемы с несколькими транзисторами, а потом восстанови из этой каши таблицу состояний, не это не то что невозможно, но просто кол-во букавок будет очень многа, а на нормальной схеме мозг сломается, так как оперативки мало.
Математику придумали просто так чтоли, это формализация, это самое первое программирование, программирование себя, разбиение на примитивы, с четкими правилами, котрые понимаю вообще все не зависимо от знания языка.
> из-за этого на нём сложнее выражать мысль, а часто сложнее понимать
Мысль о том, что было 2 козы и одну перехал трамвай и стала одна? или может вероятностную функцию какуюто проще?
>> Неа. Проще читать на русском
> O_o
> Серьезно?Нет, прикалываюсь. Похоже получается?
> Да вот фига, давай на русский переведи логику какой-нибудь схемы с несколькими
> транзисторами, а потом восстанови из этой каши таблицу состояний, не это
> не то что невозможно, но просто кол-во букавок будет очень многа,
> а на нормальной схеме мозг сломается, так как оперативки мало.А теперь попробуй на языке описания схем, написать Войну и Мир. Или вести пьяные беседы на кухне. Или расскажи о том, что такое back-propagation в нейросетке. Хоть что-нибудь кроме схем на этом языке можно выразить?
На русском читать проще. Факт, проверенный на себе.Представь себе носителя английского языка ,который в шоке задаёт вопрос: "На английском читать проще?!" (подразумевается, что весь код в мире пишется на немецком).
ДА! Они читают код НА СВОЁМ РОДНОМ ЯЗЫКЕ. И не понимают, что тут такого.
Так для справочки: Пушкин до 8 лет говорил на французском, Александр I писал приказы войскам на французском языке, при Екатерине Великой студентов универов учили на немецком, последние 20 лет код пишут почти исключительно на английском.
Прям какая-то болезненная боязнь русского языка на протяжении нескольких сотен лет, за исключением нескольких десятилетий (именно в эти десятилетия произошёл расцвет русских).
Вообще не проще, приходится постоянно вспоминать перевод чего это вообще и скажи спасибо если редактор был не совсем хлебушек. Особенно весело с совсем незнакомыми терминами на русском.
> для правостороннего присваивания значений..удобно оченЬ
.читаемой легко становится сразу программА
Ьнечо онбоду.
Аммаргорп узарс ястивонатс окгел йомеатич.
тут что-то на эльфийском…
хотя чего еще ожидать
А безопасные вставки на раст поддеоживаются?
Зачем на микроконтроллере рельсы? А если нет рельсов, то зачем вообще Ruby нужен?
Как замена однострочников перла очень неплох.
ps aux | ruby -ane 'BEGIN{$sum=0; app="Firefox"}; $sum += $F[5].to_i if $_.match?(app); END{print "#{app}:\t",$sum/1024,"\n" }'
mruby тяжеловат для мк имхо, больше как встраиваемый интерпретатор.
> Как замена однострочников перла очень неплох.
> ps aux | ruby -ane 'BEGIN{$sum=0; app="Firefox"}; $sum += $F[5].to_i if $_.match?(app);
> END{print "#{app}:\t",$sum/1024,"\n" }'
> mruby тяжеловат для мк имхо, больше как встраиваемый интерпретатор.Кхе.
ps aux|awk '/firefox/{sum+=$6}END{print sum/1024}'
ну или
ps aux|awk -v app=firefox '$0~app{sum+=$6}END{print app ":\t" sum/1024}'точно так же подсчитает "не совсем, но почти правильно" (хотя memory footprint awk все же заметно меньше руби будет, а уж на фоне FF так вообще незначителен ...)
Да там любой футпринт будет не заметен, современные браузеры столько жрут.
Собственно оно и было переписано с подобной awk, ради забавы.
> Да там любой футпринт будет не заметен, современные браузеры столько жрут.Не, я к тому, что считает оно вместе с процессом ruby/awk ;-)
====
pgrep firefox | xargs ps -o rss= -p | awk '{sum+=$1} END{print sum/1024}'
или
ps ax -o rss,comm|awk '/firefox/{sum+=$1}END{print sum/1024}'
Ps кстати врёт, да и rss тебе ни о чём не скажет -- это не информативно совершенно. Надеюсь, ты это понимаешь. И не надо использовать pgrep, pidof подходит куда больше.Я использую такой однострочник psrss=0;pspid="$(pidof ${1,,}|tr $' ' ,)";for m in `ps -eo rss= -q "${pspid}"`; do (( psrss+=m ));done; потом 3 команды bc и awk только для вывода и форматирования. Можно конечно сейчас написать иначе, но смысла переписывать не вижу.
А вот smaps тебе сообщает кроме точного rss и pss и вот это уже полезно, однострочник там ровно тот же самый только без ps.
Мне точность не сильно нужна была, однострочник служил для сравнения потребления памяти браузерами с включенным таб рипером и без. Ну и за одно выбрал какой реально выкружает вкладки, а какой только делает вид.
Там разница бывает очень значительная, особенно на программах, пытающихся скрыть своё потребление. Ну, вроде хрома. А rss вообще не отражает дистанцию до "когда зависнет", pss получше в этом отношении и сразу видно кто тут наглеет. Надёжно узнать разницу до и после можно из free (только версии свежее ~3 лет).
То есть у перловых однострочников есть фатальный недостаток? Понятно.
Ах ты такой тонкий тролль, чудо дивное, ммм (нет).
Зачем вообще лезет к микроконтроллерам человек, который не знает ничего, кроме Руби?
Что бы опровергнуть десятое правило Гринспена.
А причём здесь вообще микроконтроллеры?
> А причём здесь вообще микроконтроллеры?Это единственное место, где ещё считают килобайты.
Мне как раз руби нравится, а вот рельсами не болею. Руби - очень приятный язык для скриптов.
Его не использкют в микроконтроллерах, его используют в качестве встраиваемого языка, как Lua.
Руби красивый, хорошо продуманный язык.
К сожалению с реализациями руби изначально не везло, поэтому он так и не смог занять подобающее ему положение.
Мндаааа... ок...
А зачем?
Затем же, зачем и Lua: встраивать в программы для удобного написания высокоуровневой логики. Конкретно на mruby, например, написан гуй ZynFusion.
Встраиваемый интерпретатор. Например, в веб-серверы H2O все сложные вещи а-ля рерайты удалены из парсера конфигурационного файла, зато есть mruby с которым можно сделать практически что угодно.