Some people are happy, and some people are sad. But the truth of the matter is, as Pat mentions in a comment on Patrick’s post, Matz and Koichi are still planning to implement continuations for Ruby 2.0.
"If it’s not too hard", said Matz over breakfast. Koichi then nodded quickly and nervously, not looking up from the YARV source on his laptop (which was given higher priority real estate on the table than his breakfast plate).
Charles says he can do them in JRuby. Scott told me he had some ideas on how to do them on .NET. My money’s on Koichi for making it happen.
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.
Здравствуйте, vdimas, Вы писали:
V>Да правильно. Смотри, Java, например, "сверхсовременное" детище топталось на месте кучу лет, ибо, не успело появиться, как заболело самой популярной болезнью — преемственностью. Монстр MS взял вполне правильную политику на "обрубание хвостов". А то так и будут ср-ва вкладываться лишь в поддержку совместимости со старым.
Ну уж не знаю. Лично для меня 100% совместимость -- это святое. Отказываться от нее можно только в крайних случаях и то, с переименованием проекта. Хотят новый Ruby, так пусть его обзовут Ruby2. Тогда будет понятно, что есть mxx_ru (для Ruby 1.8.*) и mxx_ruby2 (для Ruby 2.*). А то сопровождать один и тот же проект для нескольких версий языка не весело. Радует только, что пока народ очень лихо на очередные версии Ruby переходит, но это пока пользователей языка не много.
Если же говорить о Java, то, имхо, своих целей они достигли на 1000%. Количество платформ, на которых есть Java велико (возможно, уступает только количеству платформ с C/C++, да и то, в свете J2ME еще вопрос), M$ такое только в самом счастливом сне может присниться. Пупулярность -- выше некуда, самый популярный язык, как никак (21% по сравнению с 3% у C#). Сохранение совместимости здесь сыграло очень важную роль.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Курилка, Вы писали:
К>Не знай... Есть впечатление, что МС не сильно плюёт обычно на "модные" вещи в программерском мире (ну не просто так же они далеко не один раз к явовскому сообществу "мосты" прокладывали), так что отъесть свой кусок пирога, думаю, она захочет
МС как оня боится всего непроверенного. Точнее они с удовольствием изучают опыт и испльзуют его. Но в релиз они пускают толко то что по их мнению не вызвает даже малейших сомнений.
В общем, помени мое слово. В коробку студии Руби если и попадет (в чем я лично сильно сомневаюсь), то очень не скоро.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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++.
ie>Молодцы, Немерл и Скалу еще туда и я буду счастлив
Э... ты читашь хорошо? Вот ну его на фиг чтобы Москаль или Скальски уперлись пахать в МС. Вот Москаль тут сесяц ничерта не делал как раз по причине путешествия в Рэдмонд.
Пойми, Руби для ЦЛР МС еще лет 10 не выпустит. А программиста задействуют на подсобных работах. Им скорее всего плевать на Руби. Они увидили талантливого орла и припахали его.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
На сайте O'Reilly есть подборка ссылок на блоггеров с впечатлениями о недавно прошедшей RubyConf2006. На которой Matz поделился своими соображениями о дальнейшем развитии Ruby:
Matz Rountable в пересказе Nick Sieger
Matz Keynote в пересказах Nick Sieger и Kevin Tew.
Так вот получается, что нышений Ruby будет зафиксирован как 1.8.*. И если кому-нибудь он именно такой будет нужен, то пусть он использует 1.8.*. В вот 1.9.* и 2.0 будут развиваться не оглядываясь на 100% совместимость с 1.8. Собственно, это как бы и не новость, но вот такое прямое заявление от Matz.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Пойми, Руби для ЦЛР МС еще лет 10 не выпустит. А программиста задействуют на подсобных работах. Им скорее всего плевать на Руби. Они увидили талантливого орла и припахали его.
Не знай... Есть впечатление, что МС не сильно плюёт обычно на "модные" вещи в программерском мире (ну не просто так же они далеко не один раз к явовскому сообществу "мосты" прокладывали), так что отъесть свой кусок пирога, думаю, она захочет
Здравствуйте, VladD2, Вы писали:
VD>В общем, помени мое слово. В коробку студии Руби если и попадет (в чем я лично сильно сомневаюсь), то очень не скоро.
Т.е. единственный вариант признания языка МС — попадание в студийную коробку? Есть мнение, что могут быть и не столь "выдающиеся" варианты признания микрософтом Руби, но всё это гадание на кофейной гуще, конечно, поэтому поглядим — увидим.
Здравствуйте, Курилка, Вы писали:
К>Т.е. единственный вариант признания языка МС — попадание в студийную коробку? Есть мнение, что могут быть и не столь "выдающиеся" варианты признания микрософтом Руби, но всё это гадание на кофейной гуще, конечно, поэтому поглядим — увидим.
Другие способы признания не имеют смысла с практической точки зрения. Иначе можно разводить философию на тему признания МС-ом того же Немерла. Они же ведь спонсируют его в рамках программы Ротора?
Реально МС развивает 3 языка (Васик, Шарп и С++) и поддерживает на второстепенных ролях Яву, Ява-скрипт и ФоксПро.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да правильно. Смотри, Java, например, "сверхсовременное" детище топталось на месте кучу лет, ибо, не успело появиться, как заболело самой популярной болезнью — преемственностью. Монстр MS взял вполне правильную политику на "обрубание хвостов". А то так и будут ср-ва вкладываться лишь в поддержку совместимости со старым.
Здравствуйте, eao197, Вы писали:
E>Ну уж не знаю. Лично для меня 100% совместимость -- это святое. Отказываться от нее можно только в крайних случаях и то, с переименованием проекта. Хотят новый Ruby, так пусть его обзовут Ruby2. Тогда будет понятно, что есть mxx_ru (для Ruby 1.8.*) и mxx_ruby2 (для Ruby 2.*).
Они так и делают, вроде
Ruby 1.8 будет продолжать поддерживаться (но не развиваться)
Ruby 2 будет (несколько) другой язык.
Там правда некоторый inconsistency с именованием Ruby 1.9 — он, на самом деле, не следующая версия Ruby 1.8, а экспериментальная преальфа Ruby 2
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Они так и делают, вроде ЗХ>Ruby 1.8 будет продолжать поддерживаться (но не развиваться) ЗХ>Ruby 2 будет (несколько) другой язык. ЗХ>Там правда некоторый inconsistency с именованием Ruby 1.9 — он, на самом деле, не следующая версия Ruby 1.8, а экспериментальная преальфа Ruby 2
E>Ну уж не знаю. Лично для меня 100% совместимость -- это святое. Отказываться от нее можно только в крайних случаях и то, с переименованием проекта. Хотят новый Ruby, так пусть его обзовут Ruby2. Тогда будет понятно, что есть mxx_ru (для Ruby 1.8.*) и mxx_ruby2 (для Ruby 2.*). А то сопровождать один и тот же проект для нескольких версий языка не весело. Радует только, что пока народ очень лихо на очередные версии Ruby переходит, но это пока пользователей языка не много.
Зачем сопровождать для разных версий?
Очередное обновление вполне может выйти для новой версии фреймворка. Среда ruby не такая уж большая, чтобы боятся обновить ее вместе с прикладной прогой.
E>Если же говорить о Java, то, имхо, своих целей они достигли на 1000%. Количество платформ, на которых есть Java велико (возможно, уступает только количеству платформ с C/C++, да и то, в свете J2ME еще вопрос), M$ такое только в самом счастливом сне может присниться. Пупулярность -- выше некуда, самый популярный язык, как никак (21% по сравнению с 3% у C#). Сохранение совместимости здесь сыграло очень важную роль.
К сравнению можно вернуться через 10 лет. Сейчас возрасты C# и Java отличаются в несколько раз.
На самом деле в мире Java все не так безоблачно. Если ты поставишь 5 разных Java-программ, то вероятне всего у тебя на машине осядет 5 разных Java-фреймворков. Т.е., я не вижу здесь абсолютной преемственности. Преемственность была только в опыте разработчиков при использовании самого языка и библиотек. Но блин, разве бы программисты не успевали за небольшими изменениями языка раз в 3 года?
Не верю! (С) сами знаете чей
Здравствуйте, vdimas, Вы писали:
V>Зачем сопровождать для разных версий? V>Очередное обновление вполне может выйти для новой версии фреймворка. Среда ruby не такая уж большая, чтобы боятся обновить ее вместе с прикладной прогой.
Потому что пользователи могут быть привязаны к версии 1.8.* и не иметь желания (или даже возможности) сменить себе версию.
V>К сравнению можно вернуться через 10 лет. Сейчас возрасты C# и Java отличаются в несколько раз.
В два, если мне память не изменяет
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Так вот получается, что нышений Ruby будет зафиксирован как 1.8.*. И если кому-нибудь он именно такой будет нужен, то пусть он использует 1.8.*. В вот 1.9.* и 2.0 будут развиваться не оглядываясь на 100% совместимость с 1.8. Собственно, это как бы и не новость, но вот такое прямое заявление от Matz.
С питоном в следущем году ожидается такая же ерунда. Обещают в начале года выпустить версию 3.0 не полностью совместимую с 2.х. Но при этом ветку 2.х закрывать не хотят, она будет развиватся паралельно и даже подерживать фичи (и библиотеки) из 3.х которые не ломают совместимость.
Здравствуйте, FR, Вы писали:
FR>С питоном в следущем году ожидается такая же ерунда. Обещают в начале года выпустить версию 3.0 не полностью совместимую с 2.х. Но при этом ветку 2.х закрывать не хотят, она будет развиватся паралельно и даже подерживать фичи (и библиотеки) из 3.х которые не ломают совместимость.
Я тут rest2web попробовал на python 2.5 запустить -- ругаться начало, мол import не там написан. А под python 2.4 работает нормально. Так что процесс уже пошел.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, FR, Вы писали:
FR>>С питоном в следущем году ожидается такая же ерунда. Обещают в начале года выпустить версию 3.0 не полностью совместимую с 2.х. Но при этом ветку 2.х закрывать не хотят, она будет развиватся паралельно и даже подерживать фичи (и библиотеки) из 3.х которые не ломают совместимость.
E>Я тут rest2web попробовал на python 2.5 запустить -- ругаться начало, мол import не там написан. А под python 2.4 работает нормально. Так что процесс уже пошел.
Может быть. У меня текущий проект (пишется на 2.3) без проблем пошел на 2.5
Здравствуйте, 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, как это будет выглядеть на юнихах?
