В смысле «только»? Очередной релиз Миранды — событие отнюдь не дискретное, многие фичи, упомянутые в ченджлоге, были доступны в alpha-версиях в течение N месяцев. Стабильность упомянутых alpha-версий была вполне приличная (последний месяц — вообще в основном багфиксовые preview-версии были). Если хотел пользоваться Мирандой — мог продолжать пользоваться.
Действительно, зачем тебе установленная Java Runtime Environment, если ты ею не пользуешься? Особенно в Windows, где всё так запущено. И зачем, кстати, тебе устанавливать Qt просто так, если ты им не пользуешься?
Хороший подход — это реализация основы клиента на C/C++ и дописывание всего остального на скриптах. Или наоборот, реализация компонентов клиента в виде библиотек и использование скриптов в качестве основы клиента (склейки компонентов). Это открыло бы богатый набор возможностей, который не ограничивался бы слапами.
Смотря как понимать слово «модули». Если говорить о модулях для Python, то у него есть встроенная система управления модулями (у других языков тоже есть, я думаю). Если говорить о KVIrc… Чем система управления модулями концептуально отличается от системы управления скриптами?
Что касается размера, то см. комментарий насчёт QT и Java. Скриптовый интерпретатор ставится в систему один раз (а если мы говорим о Linux, то он там скорее всего уже стоит), что не увеличивает, а наоборот — уменьшает размер скачиваемых программ. KVIrc pre-4.0 win32 весит 42 мегабайт (распакованный), из них 15 — SSL и QT.
Не буду спорить. Поскольку никто переписывать KVIrc (или его скриптование) не собирается, то и доказывать что-то мне незачем.
Применение полноценных языков выгоднее в перспективе. Программисты, знакомые с таким языком, смогут быстро и легко модифицировать программу под свои нужды. Программисты, не знакомые с этим языком, смогут его изучить. И в любом случае это позволяет использовать модули/библиотеки, доступные для этого языка (что особо актуально для Python, потому что он поставляется «с батарейками»). Для не-программистов использование широко распространённого языка облегчит написание скриптов (больше справочного материала).
При использовании самопального языка преимуществ нет вообще никаких. Я сомневаюсь, что сделать интерпретатор для нового языка легче, чем сделать биндинги для уже существующего языка.
Как это всё делается под Виндой. Без скриптов, исключительно с помощью гуёвых программ:
1) файл (ape/flac) распаковывается обратно в wav
2) cue правится, чтобы указывал на wav-файл (иногда этого не требуется)
3) cue монтируется в виртуальный оптический привод
4) с привода аудиодороги рипаются тривиально (CDex)
ублюдочнаядикая помесь аудио-проигрывателя, медиа-органайзера и браузера.Но вообще, правильно сказал.
P.S. Какие тэги Фубар выставляет при конверсии?
Действительно, зачем тебе установленная Java Runtime Environment, если ты ею не пользуешься? Особенно в Windows, где всё так запущено. И зачем, кстати, тебе устанавливать Qt просто так, если ты им не пользуешься?
Хороший подход — это реализация основы клиента на C/C++ и дописывание всего остального на скриптах. Или наоборот, реализация компонентов клиента в виде библиотек и использование скриптов в качестве основы клиента (склейки компонентов). Это открыло бы богатый набор возможностей, который не ограничивался бы слапами.
Смотря как понимать слово «модули». Если говорить о модулях для Python, то у него есть встроенная система управления модулями (у других языков тоже есть, я думаю). Если говорить о KVIrc… Чем система управления модулями концептуально отличается от системы управления скриптами?
Что касается размера, то см. комментарий насчёт QT и Java. Скриптовый интерпретатор ставится в систему один раз (а если мы говорим о Linux, то он там скорее всего уже стоит), что не увеличивает, а наоборот — уменьшает размер скачиваемых программ. KVIrc pre-4.0 win32 весит 42 мегабайт (распакованный), из них 15 — SSL и QT.
Не буду спорить. Поскольку никто переписывать KVIrc (или его скриптование) не собирается, то и доказывать что-то мне незачем.
При использовании самопального языка преимуществ нет вообще никаких. Я сомневаюсь, что сделать интерпретатор для нового языка легче, чем сделать биндинги для уже существующего языка.
Судя по сырцам, Python вызывается точно так же — python.begin и python.end
1) файл (ape/flac) распаковывается обратно в wav
2) cue правится, чтобы указывал на wav-файл (иногда этого не требуется)
3) cue монтируется в виртуальный оптический привод
4) с привода аудиодороги рипаются тривиально (CDex)
Вроде бы месяцев 7 назад кто-то начал разрабатывать Python'овый скриптовый движок для KVIrc… Вот это бы следовало бы осветить…