Здравствуйте, vdimas, Вы писали:
E>>Потому что пользователи могут быть привязаны к версии 1.8.* и не иметь желания (или даже возможности) сменить себе версию.
V>Почему? Вопрос не праздный, кстати. Ведь это скрипт-машины. Как они могут конфликтовать?
Вот пример: у меня под Windows стоит Ruby 1.8.4, поставленный из One-Click Installer. А к нему еще и штук 15-ть дополнительных RubyGem-ов. И часть из них ставилась со специфическими старыми версиями, чтобы нужный мне софт работал (с новыми отказывался) Фокус в том, что для установки нового One-Click Installer с Ruby 1.8.5 потребуется снести предыдущую инсталляцию вместе со всеми установленными RubyGem-ами (вот такая неприятная особенность пока есть в этом Installer-е). Глянув на это все я решил не менять версию 1.8.4, поскольку у меня она работает стабильно.
Еще один пример: в 2004-м mxx_ru начался для того, чтобы проще было на NonStop-ы перебраться. В то время Ruby имел версию 1.8.2, но на NonStop-е имелась в наличии только версия 1.6.8. Так что пришлось писать на Ruby версии 1.6.8. Версия же 1.8 появилась на NonStop-ах, если не ошибаюсь, только в этом году. Вполне возможно, что с будущими версиями Ruby на некоторых экзотических платформах ситуация будет аналогичной.
Кроме того, под Unix-ами, например, стандартная процедура: configure; make; make install поставит Ruby в /usr/local/bin. И оттуда будет доступна под обычным именем ruby. Установить под unix-ом несолько разных версий Ruby под разные аккаунты не так уж и просто, особенно, если машины для пользователей конфигурируются централизовано администратором.
V>>>К сравнению можно вернуться через 10 лет. Сейчас возрасты C# и Java отличаются в несколько раз.
E>>В два, если мне память не изменяет
V>Примерно в 4 пока. И кстати, справедливости ради сравнивать надо будет не Java и C#, а Java и весь .Net.
Откуда же 4?
Java -- это 94-й, т.е. 12 лет.
C# -- 2001-й, т.е. 5 лет (при том, что его прототипы, если не ошибаюсь, были доступны еще в 2000-м).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Вот пример: у меня под Windows стоит Ruby 1.8.4, поставленный из One-Click Installer. А к нему еще и штук 15-ть дополнительных RubyGem-ов. И часть из них ставилась со специфическими старыми версиями, чтобы нужный мне софт работал (с новыми отказывался) Фокус в том, что для установки нового One-Click Installer с Ruby 1.8.5 потребуется снести предыдущую инсталляцию вместе со всеми установленными RubyGem-ами (вот такая неприятная особенность пока есть в этом Installer-е). Глянув на это все я решил не менять версию 1.8.4, поскольку у меня она работает стабильно.
Понятно, в общем, проблема поддержки версионности. Если несовместимые версии хотят установится в одно место, то за это положено по пальцам давать разработчикам таких инсталляторов.
E>Еще один пример: в 2004-м mxx_ru начался для того, чтобы проще было на NonStop-ы перебраться. В то время Ruby имел версию 1.8.2, но на NonStop-е имелась в наличии только версия 1.6.8. Так что пришлось писать на Ruby версии 1.6.8. Версия же 1.8 появилась на NonStop-ах, если не ошибаюсь, только в этом году. Вполне возможно, что с будущими версиями Ruby на некоторых экзотических платформах ситуация будет аналогичной.
E>Кроме того, под Unix-ами, например, стандартная процедура: configure; make; make install поставит Ruby в /usr/local/bin. И оттуда будет доступна под обычным именем ruby. Установить под unix-ом несолько разных версий Ruby под разные аккаунты не так уж и просто, особенно, если машины для пользователей конфигурируются централизовано администратором.
в юниксе как раз будет проще всего, ибо можно сделать как с Икс-сервером, когда целевое имя — всего-лишь линк на конкретный бинарник. В общем понятно, пока мест ruby сообщество не задумывалось над поддержкой разных версий. Тогда ты прав, у тебя, как пользователя ruby возникнут серьезные проблемы, если не будет обратной совместимости.
V>>Примерно в 4 пока. И кстати, справедливости ради сравнивать надо будет не Java и C#, а Java и весь .Net.
E>Откуда же 4? E>Java -- это 94-й, т.е. 12 лет.
Первая работающая версия проекта вышла раньше.
E>C# -- 2001-й, т.е. 5 лет (при том, что его прототипы, если не ошибаюсь, были доступны еще в 2000-м).
Не бета версия вышла в 2002-м.
Здравствуйте, vdimas, Вы писали:
V>Понятно, в общем, проблема поддержки версионности. Если несовместимые версии хотят установится в одно место, то за это положено по пальцам давать разработчикам таких инсталляторов.
А это OpenSource: не нравится -- попробуй сделать лучше
Пока никто лучше не сделал
V>в юниксе как раз будет проще всего, ибо можно сделать как с Икс-сервером, когда целевое имя — всего-лишь линк на конкретный бинарник.
Да с бинарником-то полбеды. Хуже с доступом к библиотекам. Нужно прописывать отдельно переменные среды, вроде RUBYLIB и RUBYOPT.
V> В общем понятно, пока мест ruby сообщество не задумывалось над поддержкой разных версий. Тогда ты прав, у тебя, как пользователя ruby возникнут серьезные проблемы, если не будет обратной совместимости.
У меня как раз проблем нет -- я могу себе что угодно замутить.
Дело в том, что я делаю инструмент, которым будут пользоваться другие люди. А вот они могут не иметь возможности устанавливать ту версию Ruby, которую я им рекомендую. По разным причинам, начиная от элементарной лени (зачем менять то, что и так работает), до отсутствия прав на установку собственного софта на машину из-за правил безопасности. Поэтому мне, как разработчику, может потребоваться поддерживать отдельно версию своего продукта под 1.8.* и под 2.0.
Это как ситуация с Visual C++ 6.0 или GNU C++ 2.95 -- у некоторых клиентов до сих пор это официальный инструмент и софт нужно писать с поддержкой этих компиляторов.
Хотя я думаю, что в случае Ruby переход с 1.8 на 1.9 и 2.0 проблемой не будет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
V>>в юниксе как раз будет проще всего, ибо можно сделать как с Икс-сервером, когда целевое имя — всего-лишь линк на конкретный бинарник.
E>Да с бинарником-то полбеды. Хуже с доступом к библиотекам. Нужно прописывать отдельно переменные среды, вроде RUBYLIB и RUBYOPT.
Ну ok, пусть будет линк не на бинарник, а на shell-script, который установит эти переменные, а потом передаст параметры бинарнику
В общем это все не проблемы, вернее проблемы чисто организационного плана.
V>> В общем понятно, пока мест ruby сообщество не задумывалось над поддержкой разных версий. Тогда ты прав, у тебя, как пользователя ruby возникнут серьезные проблемы, если не будет обратной совместимости.
E>У меня как раз проблем нет -- я могу себе что угодно замутить. E>Дело в том, что я делаю инструмент, которым будут пользоваться другие люди.
Я именно в этом качестве тебя и имел — как пользователя ruby-инструмента. Твои пользователи — они не прямые пользователи ruby, они пользователи прикладной программы. А проблемы именно у тебя как разработчика — ты должен будешь тратить усилия на поддержку более одной ветки, либо отказаться от пользования новыми фичами.
E>Это как ситуация с Visual C++ 6.0 или GNU C++ 2.95 -- у некоторых клиентов до сих пор это официальный инструмент и софт нужно писать с поддержкой этих компиляторов.
Эти ситуации с VS 6.0 и gcc <3.x я проходил лично.
От лени все и страха перед неизвестным. Подправить код для работы под VS 7.1 легче, чем кажется на первый взгляд.
E>Хотя я думаю, что в случае Ruby переход с 1.8 на 1.9 и 2.0 проблемой не будет.
Интересно, если он будет завязан на .Net, как это будет выглядеть на юнихах?
Здравствуйте, vdimas, Вы писали:
V>В общем это все не проблемы, вернее проблемы чисто организационного плана.
Дима, так я тебе про это и говорю. У моих пользователей могут быть проблемы чисто организационного плана. А мне с этим придется считаться.
А становиться в позу, прогресс мол, нужно двигаться за мейнстримом, не сидеть на старых версиях -- это не мой путь. Когда совсем уж сил нет держать совместимость, тогда можно от поддержки старого кода отказываться. Но подталкивать пользователей к upgrade из-за того, что мне так удобно -- это пусть M$ занимается, у них опыт большой
V>Я именно в этом качестве тебя и имел — как пользователя ruby-инструмента. Твои пользователи — они не прямые пользователи ruby, они пользователи прикладной программы. А проблемы именно у тебя как разработчика — ты должен будешь тратить усилия на поддержку более одной ветки, либо отказаться от пользования новыми фичами.
Но ты забываешь, что пользователи могут использовать ruby и для других целей. И как раз эти другие цели и создадут организационные проблемы. Если пользователь ставит ruby только для моей программы -- это совсем другой расклад. А вот если он еще, к примеру, rake, ruport, rmagic и scruffy каждый день используют, то обновлять версию ruby только из-за mxx_ru они могут просто не захотеть.
E>>Это как ситуация с Visual C++ 6.0 или GNU C++ 2.95 -- у некоторых клиентов до сих пор это официальный инструмент и софт нужно писать с поддержкой этих компиляторов.
V>Эти ситуации с VS 6.0 и gcc <3.x я проходил лично. V>От лени все и страха перед неизвестным. Подправить код для работы под VS 7.1 легче, чем кажется на первый взгляд.
Уж не знаю из-за чего (может и деньги на покупку VS 7.1/8.0 тратить не хотят), но факт остается фактом -- давай им dll/lib для VS 6.0 и все тут.
А нормально написанный код вообще при переходе на VS 7.1 править не приходится
Вот только MS очередную шнягу залудила с манифестами в VS 8.0. Из-за чего мы, вероятно, будем сидеть на VS 7.1 с последующим переходом на какой-нибудь MinGW.
E>>Хотя я думаю, что в случае Ruby переход с 1.8 на 1.9 и 2.0 проблемой не будет.
V>Интересно, если он будет завязан на .Net, как это будет выглядеть на юнихах?
Он не будет завязан на .Net (как и на JVM). Для этого есть RubyCLR/JRuby.
Ладно, Дима, давай завязывать. А то так можно будет долго мячик друг другу пасовать
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
The package includes the Ruby source code (based on Ruby 1.8.5), bundled in a straight forward launcher application. An initial prooof-of-concept module has been added also.
