[programming] Скриптовые языки

Плюсую к вопросу. Тоже не понимаю толком, где должна проходить грань.

веб-сфера - скриптовые языки, так же где важна скорость разработчки (а не скорость выполнения).

Или допустим я делаю концепты в ruby\Qt (потому что быстро), а потом переношу на c++\Qt

++

Эм, там где скриптовость не будет бить по производительности и будет давать прирост скорости разработки?
Ваш К.О.
На самом деле тут вопрос в конкретном приложении и его архитектуре. Скажем если какие-то ресурсы грузятся один раз где-то в фоне, то можно эти ресурсы грузить скриптами или сами ресурсы могут быть скриптами. Так частенько в играх делают. Также гуй может быть на скриптовом языке, но при условии что не будет страдать производительность и не будет увеличиваться сильно потребление памяти и тд - а это уже возникается вопрос что за гуй и как он сделан.
В принципе значительную часть логики программ можно вынести в виде скриптов, и лиш сильножрущие операции писать на том же С или С++, так пистонисты делают частенько.
Главный вопрос какой профит получится. Потому что при разгильдяйском отношении можно не только не получить преимущества, но заработать гемороя.

Веб сфера ведь тоже разная бывает, вон гугль не зря занимается оптимизация пистона, так как жрёт много. Не всякая веб сфера непотребна к скорости.

У гугля очень большие запросы. Я думаю не стоит сравнивать нагрузку на гугли к примеру с нагрузкой на ЛОР.

Не стоит, но и то и другое - это веб. Просто если речь о небольших веб-сайтах - то так и надо писать. А то ведь вебом считаются и приложения, для которых веб - это лиш небольшая морда. Тоже самое касается и обычных приложений. Чем больше, тем серьёзнее должен быть подход к архитектуре и тем взвешеннее должно быть решение о использовании ЯП. А то заюзать сначала пистон, а потом переписывать придётся:)

Да любую. Например perl подходит для очень многих задач.

/me вчера пробовал на скриптах сделать DVD-слайдшоу - жуткие тормоза, оказалось, что проще было написать нужное на Си, что я и сделал.

Дык ядро на Си, а платформозавизимую обертку и подгрузки библиотек — на скриптах, чтоб если что поправить можно было. Не?

Такое ощущение, что большая половина ЛОРа у нас работаеют в таких проектах как Гугл.

ИМХО, нужно изначально писать на Питоне, а потом профилировать что и где долго работает или тормозит. Просто если что-то тяжелое делать на питоне - будет видно где он тормозит даже визуально и даже при самой ранней стадии разработки. Ну, я игр не писал, но если бы писал - писал бы так.

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

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

всю, какую только можно. вот что нельзя (по производительности, или ещё по каким причинами) - то пишем на C (C++, Java, whatever). вот и всей грани

> на скриптовых языках программирования, чем компилируемых?

facepalm.svg Назовешь мне пару-тройку некомпилируемых скриптовых языков?

Если взять для примера Си и Питон, то на Си нужно писать то, что должно быть гарантированно и предсказуемо быстрым, и/или должно интегрироваться в программы на других языках через стандартный интерфейс вызовов (а не какой-нибудь вид RPC).

Альтернативно, как уже сказано выше - профилирование и переписывание на Си кусков, где быстродействия Питона не хватает (а уже написанный Питон-код используется как прототип и эталон).

>Назовешь мне пару-тройку некомпилируемых скриптовых языков?

Tcl. в некотором обобщении - Prolog. насчёт Lua не знаю, но подозреваю что там тоже интерпретация на уровне исходного кода должна быть

> Назовешь мне пару-тройку некомпилируемых скриптовых языков?

Скомпилируй мне код на Perl в отдельный ELF-файл.

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

Можно предположить, что ту, для которой нужно обеспечить гибкость настройки (например для исправления баланса в игре) - исправить скрипт, не перекомпилируя приложение.

>Скомпилируй мне код на Perl в отдельный ELF-файл.

а что, кто-то говорил о компиляции в машкод?

>> Назовешь мне пару-тройку некомпилируемых скриптовых языков?

> Tcl

Это не так для версий 8.x

> Lua

Тоже нет.

Остаётся Ruby и...? Что ещё, кроме шеллов, подсказывайте знатоки.

>Это не так для версий 8.x

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

>Тоже нет.

да, там я уже заметил CLR и JVM-реализации

>Остаётся Ruby и...?

Там в 1.9 уже тоже какая-то VM, кажется.

База, которую нельзя изменять простым юзерам, - на С, а та часть, которая часто изменяется - на скриптовых. Типа, как макроязык в РПГ нужен для модописателей, которых в С пускать нельзя.

> это так даже в 8.5, с поправкой на многочисленные оптимизации процесса.

Это всё равно уже не тот чистый интерпретатор, каким были старые реализации тикля. Это в большей степени компилятор, с некоторыми исключениями для слишком динамических вещей. Хотя на практике это не имеет особого значения, пожалуй. Такая компиляция конечно совсем не то, что обычно ожидают от "компилируемого языка".

>уже не тот чистый интерпретатор, каким были старые реализации тикля

факт. но компилятор из него ещё более грязный, чем интерпретатор :)

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

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

> в некотором обобщении - Prolog

А он разве скриптовый? :) Ну и машина Уоррена опять же.

>А он разве скриптовый? :)

ну не компилируемый точно - за исключением чудо-диалекта Turbo Prolog

>Ну и машина Уоррена опять же.

это канал о сферических конях в вакууме?

>>А он разве скриптовый? :)

>ну не компилируемый точно

Мы вроде выяснили, что большинство скриптовых языков компилируются :)

> за исключением чудо-диалекта Turbo Prolog

И того самого эдинбургского Пролога Уоррена. И GNU Prolog. И SWI Prolog. И наверняка кучи других Прологов %)

>>Ну и машина Уоррена опять же.

> это канал о сферических конях в вакууме?

ДА!!!111

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

>И того самого эдинбургского Пролога Уоррена. И GNU Prolog. И SWI Prolog. И наверняка кучи других Прологов %)

не хочу тебя расстраивать, но ты несколько ошибаешься

>Мы вроде выяснили, что большинство скриптовых языков компилируются :)

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

>ДА!!!111

а вы говорите - ЛОР не торт :) что-то неизменное тут всё-таки есть

>>И того самого эдинбургского Пролога Уоррена. И GNU Prolog. И SWI Prolog. И наверняка кучи других Прологов %)

> не хочу тебя расстраивать, но ты несколько ошибаешься

Да ладно, не жалей меня. Сейчас еще раз посмотрел в гугле - таки GNU Prolog и в байткод, и в машкод компилируется, а про SWI Prolog написано просто "компиляция".

>>Мы вроде выяснили, что большинство скриптовых языков компилируются :)

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

По-моему, для ТС существенной разницей был VM или нативный код.

>По-моему, для ТС существенной разницей был VM или нативный код.

ну тогда он неверные термины выбрал

>таки GNU Prolog и в байткод, и в машкод компилируется, а про SWI Prolog написано просто "компиляция"

а теперь закрываем педивикию, пишем какое-нибудь приложение на Prolog'е (хоть GNU, хоть SWI), и смотрим - насколько это можно считать компиляцией. как и в случае Tcl я не считаю этот термин тут хоть сколько-нибудь подходящим

>> По-моему, для ТС существенной разницей был VM или нативный код.

> ну тогда он неверные термины выбрал

О чем и речь.

> пишем какое-нибудь приложение на Prolog'е (хоть GNU, хоть SWI), и смотрим

Эх, не сыпь мне соль на сахар :/

в кои-то веки спор на ЛОРе закончился согласием o_O причём параллельно в двух ветках в Talks (и оба раза - на технические темы). ад какой

Дурная затея. Как показывает практика такое обычно выливается в эпопею с профилированием и непониманием почему все и везде тормозит, а потом по переписыванию 90% кода на С++. Оставшиеся 10% на скриптовых языках в виде "клея".

Прототип на питоне надо изначально воспринимать как прототип и после написания и обкатки выкидывать полностью. Либо изначально разработывать архитектуру так, чтобы каждая часть приложения была написана на подходящем для этого языке.

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

Практика еще и показывает, что таким способом получаются и вполне быстрые программы (тот же mercurial).

> в кои-то веки спор на ЛОРе закончился согласием o_O причём параллельно в двух ветках в Talks

ЛОР уже не торт (я всегда хотел это сказать!!11)

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

именно

>ЛОР уже не торт (я всегда хотел это сказать!!11)

а мне нравится :)

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