LINUX.ORG.RU

Технологии, которые задавят Java


0

0

Интересная (хоть и спорная) статья про технологии, которые теоретически могут пошатнуть позиции технологии Java.

Так же стоит почитать обсуждение этой статьи: http://lambda-the-ultimate.org/node/v...

>>> Bruce Tate: Technologies that may challenge Java



Проверено: ivlad ()

Ответ на: комментарий от r

>о что он приводит как недостаток java называется Manifest Typing. Отсутсвие необходимости декларации типов - не есть преймущество динамических языков. В статических языках HAskell, StandrdML/OCAML используется техника называемая http://c2.com/cgi-bin/wiki?TypeInference которая возволяет выводить типы всех объектов.

Есть некий метод "Ф", кот. у кот-го принимает есть неки параметр "а", внутри этого метода есть такая муйня а.метод1(), а.метод2(), а.поле1, а.поле2. У нас есть два объекта некоторых классов, таких, что у обоих есть метод1, метод2, поле1 и поле2 и они НЕ НАСЛЕДУЮТ общего интерфейса. В Питоне или Руби, мы свободно эти объекты, при вызове этого "Ф". Фсе работает. Вопрос сумеет ли хаскел или окамл работать с этой муйней? ответ хрен. Это называется параметрический полиморфизм.

anonymous
()
Ответ на: комментарий от anonymous

>Я согласен с вами относительно дженериков, однако зачем делать сложно то, что можно сделать просто. В Смолтоке динамические типы были изначально, однако именно они считались "недостатками", когда на смолток наезжали маркетоиды от жабы.

Да блин не в этом дело!!! Отсутсвие манифестации типа - не есть "динамичность" языка. Я же привел пример двух языков которые являются _статически_ типизированными и тем не менее манифестации типов нам вещь опциональная, когда нужно наложить констрейнты котрые нужны жеcтче чем может вывести компилятор.

А dynamic vs static - это известный холи вар - его открывать не будем. ГЕнерики офмф к динамическим типам имеют вообще никакое отношение - это просто кривенная попытка реализации parametric polymorphism, и она тоже статическая, (вообще в динамических языках такого нет - оно там не нужно - там все на отвественности программиста).

И Брюс сделав эту заметку (буквально повторил Эккеля слово в слово) просто воткнулся в очередной холи вар, при этом продемонстрировал свою необразованность в данном вопросе, да еще проявив красноглазость утверждая что ruby лучше java потому как "dynamic".

r ★★★★★
()
Ответ на: комментарий от anonymous

>Вопрос сумеет ли хаскел или окамл работать с этой муйней? ответ хрен. Objective Caml version 3.08.2 # class dog =

object

method say = "Wow"

end;;

class dog : object method say : string end

#class cat =

object

method say = "Myaw"

end;;

class cat : object method say : string end

# let say e = e#say;;

val say : < say : 'a; .. > -> 'a = <fun>

# say new dog;;

- : string = "Wow"

# say new cat;;

- : string = "Myaw"

Ыыыы?

r ★★★★★
()
Ответ на: комментарий от r

> утверждая что ruby лучше java потому как "dynamic".

утверждая что ruby лучше java ДЛЯ ОПРЕДЕЛЕННОГО ВИДА ЗАДАЧ, потому как "dynamic".

anonymous
()
Ответ на: комментарий от anonymous

>утверждая что ruby лучше java ДЛЯ ОПРЕДЕЛЕННОГО ВИДА ЗАДАЧ, потому как "dynamic".

А не затруднит указать где это написал Брюс? Потому что для определенного вида задач действительно динамик лучше. Только ведь брюс где об этом сказал брюс? Он сказал что запись на _динамическом_ языке короче чем на статическом. Он неправ.

r ★★★★★
()
Ответ на: комментарий от int19h

А этот магазин домашних животных насколько шустрее J2EE бегать будет?

anonymous
()
Ответ на: комментарий от r

Брюс прав. И не тлько Брюс:

http://www.whysmalltalk.com/2005/02/smalltalk-v-java-which-is-more.htm

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

lineCount
   | cr count |
   cr <- Character cr.
   count <- 1  min: self size.
   self do:
      [:c | c == cr ifTrue: [count <- count + 1]].
   ^ count

При этом все лексеммы, кроме знаков препинания, объекты, 
нет рэппинга и дополнительного оут-ин-боксинга.

Для своих задач также подходят Ruby, ocaml, LISP, tcl/tk, python, ...

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

anonymous
()
Ответ на: комментарий от anonymous

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

entrpriZe руководствуется не только качеством языка (и даже не в первую очередь). То и платформой, наличием библиотек, и стоимостью проекта равно как и оплатой труда. Загляните на jobовый сайт и что вы там найдете? У нас есть продукт который работает: на Win/Lin/Solaris/OS9/OSX/Irix, распределенный, работает как server/standalone/applet под всеми живучими бровзерами, имеет веб интерфейс, command line, GUI интерфейс. Нука вперед придумывать на каком языке его надо было делать, с учетом потенциальных проблем и ограничений - красота языка тут не самая большая проблема. И продукт немаленький - наличие готовых библиотек это есть хорошо и экономия, а не как кто-то тут отвечал "да я за две недели биндинги...."

ТАк что enterpriZe штука сложная и удобство продвинутых программистов - не самый серьезный фактор в enterpriZe. Вона скока народу на VB пишет - и ничего....

r ★★★★★
()
Ответ на: комментарий от r

>Ыыыы?

1)Там еще к полю обращение было. Ыыыыы?

2)Таперича добавляем в dog и cat в рантайме метод eat скажем и зовем его. Ыыыы?

3)А про continuation в жаба Ыыыы?

Ыыыы. Прошу заметить, что я не передергиваю. В Питоне и Руби это делается на раз.

anonymous
()

что то на Руби слишком много надо нажимать кнопок,
вот так кошернее :) -
fibs = 1 : 1 : [ x + y | (x,y) <- (zip fibs (tail fibs))]

rusl
()
Ответ на: комментарий от rusl

Народ, вы вдумайтесь, сравниваются две платформы, Java, в которую вбухано сотни мегабаксов, и Ruby, поддержка энтузиастов. Уже это говорит об неэффективности Java.

anonymous
()
Ответ на: комментарий от anonymous

>1)Там еще к полю обращение было. Ыыыыы?

По твоему тут имеется разница? Ты хоть понимаешь что в этот момент происходит и как достигается?

>2)Таперича добавляем в dog и cat в рантайме метод eat скажем и зовем его. Ыыыы? >3)А про continuation в жаба Ыыыы?

Не ыыыы. Эта фишка существует в языках с динамической типизакицей - не если ты уж захотел мерятся - покажешь мне в питоне algebraic types и pattern matching? Нет? Фтопку.

Если ты красноглазик меряешь языки по каким-то абсолютным критериям безотносительно задачи и окружающих факторов - то не заслуживаешь даже чтобы тебя потом оплакивали.

r ★★★★★
()
Ответ на: комментарий от anonymous

> Варианты того же на J2EE и на .NET нервно отдыхают у параши...

Давно так не смеялся - ты хоть сам то это смотрел?

anonymous
()
Ответ на: комментарий от anonymous

>Народ, вы вдумайтесь, сравниваются две платформы, Java, в которую вбухано сотни мегабаксов, и Ruby, поддержка энтузиастов.

А если я сейчас накатаю материал, где буду сравнивать Jython с моим JBForth, например? :D Это тоже скажет о неэффективности Jython? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от r

>окажешь мне в питоне algebraic types и pattern matching

Что в огороде лебеда, а в киеве дядька? Ну напиши еще что у тебя срака больше чем у лучиано.

>По твоему тут имеется разница?

Разницы нет, однако надоели уже некоторые товарищи, которые выдергивают фразы из контекста или отвечают только на часть поставленного вопроса. Про континюэйшн я тебя уже три раза спросил, и ты еще не показал, как с помощью жаба и ассиста зделать что то типа активрекорд. Что недышишь? А как дышал!

>Ты хоть понимаешь что в этот момент происходит и как достигается?

Я то понимаю. А ты? Сомнительно. Иначе бы сразу и написал.

>Если ты красноглазик меряешь языки по каким-то абсолютным критериям безотносительно задачи и окружающих факторов - то не заслуживаешь даже чтобы тебя потом оплакивали.

Все, что я тебе попытался втолковать - это то, что основной мыслью Брюса было не то, что паралельное присваивание есть в Руби, или то, что какая то херня там короче записывается, а то, что есть очень большой класс задачь, для которых где языки подходят значительно лучше, вот там нужно и по клаве меньше стучать и результат будет значительно быстрее. А паралельное присваивание - это утрировано, для дурачков типа сам знаешь кого. Ты кстати не показал как зделать Брюсовский пример с Активрекорд на жаба и ассисте.

>Не ыыыы. Эта фишка существует в языках с динамической типизакицей

Ну наконец то! Кажется прогресс пошел! Долго же до тебя доходит.

anonymous
()
Ответ на: комментарий от anonymous

>Брюс прав. И не тлько Брюс:

Блин! Вот этого | cr count | и нехватает во всяких там питонах и рубях!

anonymous
()
Ответ на: комментарий от r

> 3)А про continuation в жаба Ыыыы?
>
> Не ыыыы. Эта фишка существует в языках с динамической типизакицей

Так, стоять. Почему continuation подразумевает динамическую типизацию?

int19h ★★★★
()
Ответ на: комментарий от r

> Не ыыыы. Эта фишка существует в языках с динамической типизацией - не если ты уж захотел мерятся - покажешь мне в питоне algebraic types и pattern matching? Нет? Фтопку.

А может еще про классы типов вспомнить? ;-)

Begemoth ★★★★★
()
Ответ на: комментарий от Begemoth

>А может еще про классы типов вспомнить? ;-)

И ешо в Питоне нету шаблонов С++ ( pattern matching там что называется in place), макросов CommonLisp-а, мультиметодов, кадила и гармони!

anonymous
()
Ответ на: комментарий от r

>Дfун Эккель када писал статью тоже мерял жава с питоном на тему инамичности сравнивая отсутствие необходимости декларировать общий нтерфейс и хвалил питон как динамический язык показывая насколько меньше кода.....

Дfун - видимо Даун. Крутые чуваки на лоре! Чем больше читаю, тем больше удивляюсь!

>пришлось указать, и показать как тоже код на статически типизированном OCamlе занимает столько же и обладает всеми теми же ствойствами что и питон в примеденном примере, но при этом еще и статически типизирован.

Опля! А OCaml то тут причем? Плавное перетекание от жабы ( уж на что жаба мерзко звучт, а джава еще хуже!) к OCaml-у заставляет задуматься, а не нарушена ли у дорогого r причинно/следственное восприятие? Говорят такое бывает при некоторых распространенных формах шизофрении.

anonymous
()
Ответ на: комментарий от anonymous

>Что в огороде лебеда, а в киеве дядька?

Ты блин, баран, так и не понял в чем проблема этой статьи и суть моих претензий. Ты как и Брюс кинулись сравнивать java и ruby по каким-то абстрактным абсолютным критериям как то наличие continuations и отсутсвие необходимости декларировать типы. Про первое я показал аналогией про AT и PM что если например сравнивать тот же OCaml и ruby по наличию упомянутых - окажется что руби сосет. Это по вопросу фичастости, а по вопросу динамической типизации ты быстро заткнулся когда увидел свой пример только на статическом языке только без манифестации типов? Что показывает что Брюс нефига не разбирается в том о чем пишет.

>Я то понимаю.

Что-то сомнительно - судя по тупорылым вопросам на счет "там еще поле было" и упоминатия параметрического полиморфизма в контексте динамических языков. Если ты не в курсе сама фишка полиморфизма - это из раздела статической типизации которое отсутсвует в динамических языках (не считая так называемого ad-hoc полиморфизма (method overload) - он есть везде).

>Все, что я тебе попытался втолковать - это то, что основной мыслью Брюса было не то

А покажешь мне эту основную мысль в качестве выдержки из оригинала? А то извини - но мои скромные познания в английском видят только то что динамическая типизация одна из четырех основных киллеров джавы.

r ★★★★★
()
Ответ на: комментарий от int19h

>Почему continuation подразумевает динамическую типизацию?

ДА эта не подразумевает - это я хотел ответить на 2,3 раздельно а потом пересунул 3 слишком высоко. Это я про добавление методов на лету.

r ★★★★★
()
Ответ на: комментарий от Begemoth

> А может еще про классы типов вспомнить? ;-)

Да про много чего можно вспомнить. Языков много хороших и разных, которые применимы в том или другом случае, и зависит это не только от фич языка в абсолютном виде (типа там наличие continuation) но и от многих внешних факторов - наличие библиотек, фреймворков, целевой платвормы, производительности, и т.д. И сравнивать по критерию "в джава статическая типизация - java suxx", "в руби есть continuation - руби наш бохх" - это дилетанство.

r ★★★★★
()
Ответ на: комментарий от anonymous

А самое главное там нет возможности Perl, написать такой код, что даже опытные гуру проспорят тебе коньяк.

Sun-ch
()
Ответ на: комментарий от anonymous

>Говорят такое бывает при некоторых распространенных формах шизофрении.

Люди вообще делятся неа две категории - у одних распространенная форма шизоидности у других паранойи - если уровень того или другого становиться абнормальным - применяют специальные методы стабилизации.

>А OCaml то тут причем?

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

И потому дорогой анонимус следствие (оствутствие необходимости в излишних декларациях) никак не проистекает из причины динамическая типизация, так как в случае статической типизации OCaml и Haskell мы наблюдаем схожее следствие. Так что с причинно следственной связью у меня все в порядке.

r ★★★★★
()
Ответ на: комментарий от r

> ДА эта не подразумевает - это я хотел ответить на 2,3 раздельно а
> потом пересунул 3 слишком высоко. Это я про добавление методов на
> лету.

Кстати, а если поставить вопрос так: "что нужнее - возможность менять
класс в рантайме, или pattern matching" - тогда что? ;)

int19h ★★★★
()
Ответ на: комментарий от int19h

>Кстати, а если поставить вопрос так: "что нужнее - возможность менять класс в рантайме, или pattern matching" - тогда что? ;)

Лично мне из опыта - pattern matching. Я себе слабо представляю необходимость таких изменений разве что в замкнутых средах типа smalltalk, где сама разработка - это рантайм и есть.

r ★★★★★
()
Ответ на: комментарий от int19h

>Кстати, а если поставить вопрос так: "что нужнее - возможность менять класс в рантайме, или pattern matching" - тогда что? ;)

То, что можно зделать с помощью pattern matching, можно зделать и без него. Иногда громоздко, неудобно - но можно.

Возможность менять класс в рантайме, вещь полезная и если нет изначально - не пришьешь. Чем полезна? Пример из статьи, где класс генерится на основе информации из базы данных, тут еще работает метапротокол ( там где говорится, что Persons has_many :cars ).

Это забавный пример - объявляется пустой класс, а строчкой ниже идет обращение к несуществующим полям этого класса.

anonymous
()
Ответ на: комментарий от anonymous

> Это забавный пример - объявляется пустой класс, а строчкой ниже идет обращение к несуществующим полям этого класса.

Вот именно пример забавный - не более. Если ниже идет обращение к несуществующим полям - значит об их существовании известно в design time. И поскольку если логика уже работающая с недекларированными полями - непонятен смысл всего этого. Если эти поля должны быть полюбому - какой смысл их строить динамически?

r ★★★★★
()
Ответ на: комментарий от r

> Вот именно пример забавный - не более. Если ниже идет обращение к
> несуществующим полям - значит об их существовании известно в design
> time. И поскольку если логика уже работающая с недекларированными
> полями - непонятен смысл всего этого. Если эти поля должны быть
> полюбому - какой смысл их строить динамически?

А они декларированы на самом деле, просто не в коде, а в БД.
Декларировать их по второму разу в коде - а зачем лишний раз
повторяться?

Хотя, строго говоря, dynamic typing для этого не нужен. Достаточно
полноценных макр. На Lisp или там Nemerle вполне можно такое же сделать.

int19h ★★★★
()
Ответ на: комментарий от int19h

>Хотя, строго говоря, dynamic typing для этого не нужен. Достаточно полноценных макр. На Lisp

Дык Lisp он вроде и есть dynamic typing по умолчанию. А ROR говорят динамически базу можно менять и он будет адаптироваться. На макрах такого не зделать.

anonymous
()
Ответ на: комментарий от int19h

> А они декларированы на самом деле, просто не в коде, а в БД. Декларировать их по второму разу в коде - а зачем лишний раз повторяться?

Ну - тут обоснование можно привести только статическое ;): потому что BD и код статически развязаны и не валидируются на соответствие.

>Хотя, строго говоря, dynamic typing для этого не нужен. Точно.Посмотри как это делается в Cw (будет с следующем C#?). Там они SQL на уровне языка намутили и он возвращает структуры. http://research.microsoft.com/projects/comega/doc/comega_tutorials_sqlquery.htm

r ★★★★★
()
Ответ на: комментарий от int19h

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

Однако возможна ситуация, когда состояние БД не соответствует тому, что об этом думал программист (скажем пришел DBA и позаменял, неподумавши, строки цифр на number-ы, или наоборот). Опосля чего программа начинает при тривиальной попытке посчитать сумму разбрасывать исключения налево и направо, жрать всю память для очень-длинной-строки, или еще что-нибудь экзотическое.

По этой причине в программе _нужно_ держать обьявление/проверку ожидаемых от БД типов. А раз так, то пример опять только забавный.

А если не заботиться об контроле типов, очень легко определить требуемый "читаемый из БД класс" как какой-нибудь FiniteMap, строка -> строка, и явно писать парсинг, где нужно, и будет почти то же, что и в случае "динамических" языков. И даже без макр.

DonkeyHot ★★★★★
()
Ответ на: комментарий от rusl

> вот так кошернее :) - > fibs = 1 : 1 : [ x + y | (x,y) <- (zip fibs (tail fibs))]

Так ещё кошернее:

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

anonymous
()
Ответ на: комментарий от DonkeyHot

> Однако возможна ситуация, когда состояние БД не соответствует тому,
> что об этом думал программист (скажем пришел DBA и позаменял,
> неподумавши, строки цифр на number-ы, или наоборот). Опосля чего
> программа начинает при тривиальной попытке посчитать сумму
> разбрасывать исключения налево и направо, жрать всю память для
> очень-длинной-строки, или еще что-нибудь экзотическое.

Да нет, она просто брякнется с "incompatible type X" или "object Y does
not have method Z".

int19h ★★★★
()
Ответ на: комментарий от anonymous

> Дык Lisp он вроде и есть dynamic typing по умолчанию.

Имелось в виду - без прибегания к DT. Впрочем да, Nemerle - более
типичный пример.

> А ROR говорят динамически базу можно менять и он будет
> адаптироваться.

Во время выполнения??

Это ж убивать за такое надо...

А так при перезапуске что dynamic, что на макрах, оно подцепит
изменения.

int19h ★★★★
()

Ruby:
x1, x2 = 1, 0
Java:
int x1 = 1;
int x2 = 0;

IMHO Текст программы должен легко читаться.
Рассмотрим пример:

x1,x2,x3,x4,x5,x6,x7,x8,x9 = 1, 0, 0, 1, 0, 1, 0, 1, 0 ,1

вопрос, чему равно значение x6? Ответ, - надо считать (а за такой код, мягко говоря, -ругать).
Преимущества такого подхода весьма сомнительны, а места для ошибок есть.Например в инициализаторе ошибка, я лишнюю единичку написал, заметили? ;-)

для таких констукций есть Array
int[] x= {1,2,3,4,5};

так что
Ruby:
x1, x2 = 1, 0
java
int [] x={1,0};

Читаем статью дальше.
Метропрограммирование.
Оно есть в java уже давно.

ORM.
В Java ORM появились давно. Хорошие &#8211; Hibernate,Oracle TopLink, JDO, JSR 220 (aka EJB3)

ORM от Ruby годится только для очень простых вещей, чего стоит ограничение на то, что у вас имена столбцов должны совпадать с полями объектов.
(Собственно на serverside Брюс сам в этом покаялся)

всё? И получается, что из этого автор считать можно сделать вывод? Забавно...

А ведь в статье опущено много других важных вопросов:
Производительность - говоря местным языком, если бы Томи был на Ruby-он бы остался жив (стоял бы себе на старте).

Приемлемые средства разработки - для Ruby практически отсутствуют.

Юникод - Ruby не знает до сих пор.

Библиотеки.
Безопасность.
И это только вершина айсберга.

Из опыта людей работавших с ruby больше чем я.
Ruby подходить только для один человек/один месяц проектов.

Теперь касательно Брюса, а вернее Брюсов.
Два Брюса - Экель и Тэйт теперь ругают Java почему?
Ответ кроется в том, что эти господа зарабатывают себе на жизнь &#8211; педагогикой и изданием книг.
На книгах про Java стало очень сложно заработать, очень уж много "писателей" отметилось.
Что остается работникам пера?
Ответ: Получать прибыли с тех, кто считает, что по
puts "Hello, world."
vs
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!")
}
}
можно сделать вывод.






Yilativs ★★★★
()
Ответ на: комментарий от Yilativs

>x1,x2,x3,x4,x5,x6,x7,x8,x9 = 1, 0, 0, 1, 0, 1, 0, 1, 0 ,1

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

>Метропрограммирование.Оно есть в java уже давно.

Смотря что называть метапрограммированием. Если речь идет об аннотациях и прочих рефлексии или хаканья байткода на лету - вряд ли.

>ORM от Ruby годится только для очень простых вещей,

Незнаю - нещупал. Однако из статьи - декларативные возможности неплохие.

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

Ерунда - можно пережить, если базуху дизайнил не первокласник.

>Производительность

Хреновая.

>Юникод - Ruby не знает до сих пор.

Да уж!!!

>Библиотеки.

Вроде полно.

>Теперь касательно Брюса, а вернее Брюсов.Два Брюса - Экель и Тэйт теперь ругают Java почему?

Dynamic languages will not completely replace Java, but they will be more attractive for small, lightweight problems.

Вроде не ругают, а говорят, что дескать и вам тута место есть (для всяких там маленьких приблуд), а не только для java. Я с ним согласен. С чего это все вдруг решили, что Брюс опускает java?

anonymous
()
Ответ на: комментарий от Yilativs

> IMHO Текст программы должен легко читаться.
> Рассмотрим пример:
>
> x1,x2,x3,x4,x5,x6,x7,x8,x9 = 1, 0, 0, 1, 0, 1, 0, 1, 0 ,1
>
> вопрос, чему равно значение x6? Ответ, - надо считать (а за такой
> код, мягко говоря, -ругать). Преимущества такого подхода весьма
> сомнительны, а места для ошибок есть.Например в инициализаторе
> ошибка, я лишнюю единичку написал, заметили? ;-)

Угу. Теперь напишите мне на жабке:

x1, x2 = x2, x1

и сравним, где код короче и понятней =)

> Читаем статью дальше.
> Метропрограммирование.
> Оно есть в java уже давно.

Хотя бы динамическое добавление методов в класс есть?

AFAIK, есть только аннотации и извращения с ClassLoader'ом.

> ORM от Ruby годится только для очень простых вещей, чего стоит
> ограничение на то, что у вас имена столбцов должны совпадать с полями
> объектов. (Собственно на serverside Брюс сам в этом покаялся)

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

> А ведь в статье опущено много других важных вопросов:
> Производительность - говоря местным языком, если бы Томи был на
> Ruby-он бы остался жив (стоял бы себе на старте).

Есть такое. Видимо, предполагается, что для Web-приложения критичным
является скорость выполнения запросов к базе.

> Приемлемые средства разработки - для Ruby практически отсутствуют.

Я вообще специально не смотрел, но судя по скринам, Mondrian - весьма
продвинутая вещь.

Ах да, еще есть плагин RDT для Eclipse.

> Юникод - Ruby не знает до сих пор.

Знает (require 'jcode'), но криво. Это, пожалуй, самая большая
претензия к нему сейчас

> Библиотеки.

Дело наживное. Rails - это как раз попытка создать нужную надстройку
над Ruby.

> Безопасность.

Есть оно там, и достаточно грамотно сделано, кстати.

А сабжевая статья действительно бестолковая и даже в некотором
смысле позорная. За Ruby (или его идеологическими потомками) однозначно
будущее, но никак не настоящее =)

int19h ★★★★
()
Ответ на: комментарий от Yilativs

Ха, все проще

в Ruby
x = [1, 2, 3, 4, 5]
создаст необходимый массив.

А на счет Hello World нужно действовать __объектно__, то есть
"Hello World!".display

anonymous
()
Ответ на: комментарий от int19h

>Угу. Теперь напишите мне на жабке:
>x1, x2 = x2, x1

А теперь скажи где это нужно?
Много при разработки Web приложений ты так делал?
И если делал то зачем?

>Хотя бы динамическое добавление методов в класс есть?
Нету, и признаться ни разу небыло нужно. Зачем?
Давайте идти от потребностей.

>>ORM
>Нет там уже давно такого ограничения. Это удобное умолчание, но можно
сделать явную ассоциацию между двумя произвольными именами.

Right Outer Join с условием можно сделать? ;-)

>IDE Я вообще специально не смотрел, но судя по скринам, Mondrian - весьма продвинутая вещь.Ах да, еще есть плагин RDT для Eclipse.

Первый не трогал, второй пока никакой.
Cам в VIM пишешь?

> Библиотеки.
Дело наживное. Rails - это как раз попытка создать нужную надстройку
над Ruby.
Согласен, будут библиотеки, но сейчас их мало.
Зато есть возможность добавить в класс метод на лету ;-)

>> Безопасность.
>Есть оно там, и достаточно грамотно сделано, кстати.
Есть ли аналог JAAS или acegi?
Ты SPNEGO или хотя бы NTLM аутентификацию делал на Ruby?

Yilativs ★★★★
()
Ответ на: комментарий от anonymous

>Пользую Ruby в реальном аналитическом проекте уже год. 7 девероперов разной квалификации стали писать в течение недели без проблем под Linux+Ruby+FXRuby, до этого у них был опыт Windows + Delphi.

Конкретнее, что анализируете?

anonymous
()
Ответ на: комментарий от int19h

>просто брякнется с "incompatible type X" или "object Y does not have method Z"

Не знаю как в руби, а в питоне сложение и умножение на целое число одинаково применимы к строкам и к разным численным типам. А результаты разные. Так что есть шансы получить неизвестно что.

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

>Вроде не ругают, а говорят, что дескать и вам тута место есть (для всяких там маленьких приблуд), а не только для java. Я с ним согласен.

Да чушь это. Почитайте The Art of Java. By: Schildt, Herbert Holmes, James ISBN: 0072229713 Маленькие приблуды продолжают успешно писать на Java.

А как только сайт на RoR вырастет до размеров linux.org.ru, так сразу Ruby не потянет и придется слезать на J2EE, так лучше уж сразу и закладываться на J2EE

anonymous
()
Ответ на: комментарий от int19h

>Дело наживное. Rails - это как раз попытка создать нужную надстройку над Ruby.

Угу. Spring, Hibernate изобрели для Java. Теперь энтузиасты усиленно портируют это дело под .NET. Потом окажется, что неплохо бы иметь свой Spring и в Ruby, и Ruby превратится в Java 2 (или 3? ;))

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.