Здравствуйте, Igor Trofimov, Вы писали:
iT>Кстати, perl-гуру тебе килотонну таких фишек набросает. iT>Вот только ты скажешь, что это ужас, а не фичи, а он — что это кул
Видимо я плохо знаю Перл, но я низнаю ни одной вещи из Перла которой нет в Яве. Просто многие встроенные в Перл фичи в Яве вынесены в библиотеки. Те же хэш-таблицы или регексы...
... << RSDN@Home 1.1.2 beta 3 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Видимо я плохо знаю Перл, но я низнаю ни одной вещи из Перла которой нет в Яве. Просто многие встроенные в Перл фичи в Яве вынесены в библиотеки. Те же хэш-таблицы или регексы...
VD>Видимо я плохо знаю Перл, но я низнаю ни одной вещи из Перла которой нет в Яве. Просто многие встроенные в Перл фичи в Яве вынесены в библиотеки. Те же хэш-таблицы или регексы...
Я перл тоже знаю плохо. Думал, что знаю (вроде бы скриптов разных по необходимости писано-переписано), уже но почитал CamelBook и понял, что не знаю Не то, чтобы жалею, что не знаю, все-таки он повергает меня в ужас своим стилем, но познакомиться поглубже было как минимум любопытно.
Когда автор языка проводит параллели между конструкциями языка программирования и естественным языком и этим объясняет, почему что-то сделано так, а не иначе — это весьма интересно. Проверить собственные стереотипы типа "как в современных ЯП делают ООП" на крепкость (а после ООП от перл эти стереотипы жутко трещат) тоже наверное полезно.
Впрочем, сравнивать по возможностям перл с java как-то очень бестолково — они очень разные. Вопрос возникает не "это в java есть или нет", а "нафига это нужно". Если программа пишется в стиле perl, то это видимо, нужно Операнды по умолчанию.. "and" и "&&" с разным приоритетом... if "спереди" и "сзади"... анонимные подпрограммы... подмена стандартных функций... перегрузка операций чтения и записи для переменной, и прочее, прочее... Все эти вещи в терминах такого языка как java просто лишены смысла, не так ли?
Совершенно разные парадигмы и, немного подумав, я уже не понимаю, как их можно сравнивать. на вопрос типа "можно ли решить такую-то задачу" любой язык программирования отвечает "ДА", даже XSLT, как недавно кто-то доказал.
На вопросы типа "можно ли в java сделать функцию с переменным числом параметров и вернуть из нее в зависимости от контекста вызова — либо скаляр, либо вектор" и "можно ли в perl сделать функцию, при использовании которой разработчик обязан перехватить ошибку или объявить, что из его функции может вывалиться эта ошибка" — неизбежно следует ответ "а нафига это надо" от противоположеной стороны. И они правы. Очень разные языки, очень разные ниши (что бы не говорили приверженцы perl'а).
Здравствуйте, Igor Trofimov, Вы писали:
iT>Впрочем, сравнивать по возможностям перл с java как-то очень бестолково — они очень разные. Вопрос возникает не "это в java есть или нет", а "нафига это нужно". Если программа пишется в стиле perl, то это видимо, нужно Операнды по умолчанию.. "and" и "&&" с разным приоритетом... if "спереди" и "сзади"... анонимные подпрограммы... подмена стандартных функций... перегрузка операций чтения и записи для переменной, и прочее, прочее... Все эти вещи в терминах такого языка как java просто лишены смысла, не так ли?
Вот Шарп такой язык как Ява? Я к тому, что все что ты перечислил или есть в нем, или появится в следующей версии. Но! Но от этого код на нем не становится нечитаебельным птичьим языком.
iT>Совершенно разные парадигмы и, немного подумав, я уже не понимаю, как их можно сравнивать.
Сравниваются они легко. И у Перла даже есть приемущества... там где нужно написать скрипты для быстрого решения задачь. Но в области построения надежных, больших, масштабируемых систем перлу места нет.
... << RSDN@Home 1.1.2 beta 3 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 -> "Re[30]: Помогите мотивировать начальство" :
V> Здравствуйте, hrg, Вы писали:
hrg>> это чтение из хандлеров. Но это bad style. При использовани таких hrg>> выражений большой риск подмены значений в $_.
V> Вот представь себе, что Ява и особенно C# проектировались так, чтобы V> бэд-стайл не мог даже появиться.
Вот тебе аналогия.
Есть поезд. А есть машина. Поезд с рельсов хрен свернешь. Машина может
проехать практически где угодно. Но почему то ездят как поезда, так и
машины. Каждый иснтрумент хорош для своей работы.
iT>>Операнды по умолчанию.. "and" и "&&" с разным приоритетом... if "спереди" и "сзади"... анонимные подпрограммы... подмена стандартных функций... перегрузка операций чтения и записи для переменной, и прочее, прочее... Все эти вещи в терминах такого языка как java просто лишены смысла, не так ли?
VD>Вот Шарп такой язык как Ява? Я к тому, что все что ты перечислил или есть в нем, или появится в следующей версии.
Да ну? Надеюсь, что все-таки не появится.
Насчет нечитабельности — с одной стороны — согласен, с другой... черт его знает.. Вот китайский язык для меня совершенно нечитабелен, но если его хорошо выучить, чтобы думать на нем, то может другой человек, который хорошо знает китайский — поймет меня быстрее и мысль выразится лаконичнее? Естественно, всем носителям европейских и славянских языков китайский кажется "write only" Как мне и тебе — perl.
Здравствуйте, Blazkowicz, Вы писали:
B>Здравствуйте, _vovin, Вы писали:
B>>>Все будет зависить от иерархии и реализации загрузчиков классов. B>>>Банальный пример: берем тот же томкат. B>>>Делаем 2 вэб приложения, которые используют, разные версии классов. B>>>Деплоим на томкате. Результат: одна JVM, два класса, все работает.
_>>Тривиальный случай сферического коня. B> Очень аргументированно опротестовал.
Указанный случай неявно вводит следующие ограничения:
1) Разные версии классов не взаимодействуют между собой.
2) Разные версии классов не взаимодействуют с другими классами, которые могут быть загружены позже и у них будет одинаковая версия.
3) Не требуется хранить экземляры классов в памяти, которые при обновлении версии должны быть автоматически конвертированы в новую версию.
Если бы в реальных приложениях было так просто, я бы не встречал ошибок несовпадение версий классов.
B>>>Если не понятно и интересно как работает, почитай про ClassLoader'ы. B>>>На нормальных серверах приложений делают свои реализации загрузчиков, которые нормально справляются со всеми описанными тобой проблемами.
_>>Они даже теоретически не могут справиться с указанной проблемой. Главное препятствие — отложенная загрузка классов. B>Обоснуй.
B>Работают одни классы. Захотелось расширить функциональность — пжалуста, тормозим поток с его загрузчиком, обновляем классы, запускаем. Всё.
B>Проблема совсем в другом. Если один и тот же класс был загружен разными загрузчиками, то это уже 2 разных класса. Поэтому взаимодействие остального кода с перегружаемым нельзя реализовать тривиально.
При разработке типичного веб-приложения требуется и взаимодействие и хранение экземпляров классов, поэтому перегружать сервер требуется постоянно.
Все началось с утверждения о кривых руках. Теперь оказалось, что многое реализовать нетривиально (значит не реализовано сейчас?).
Так что давайте заберем свои слова обратно.
VladD2 -> "Re[20]: Помогите мотивировать начальство" :
V> Здравствуйте, hrg, Вы писали:
hrg>> Потомучта знаю perl и его возможности.
V> Тебе не кажется, что для сравнения с Явой еще неплохо было бы знать и V> ее?
Кажется. Но найди хоть один мой постинг, где я ругаю Яву? Продолжаем...?
VladD2 -> "Re[18]: Помогите мотивировать начальство" :
hrg>> Я не силен в джаве
V> И что тогда рассуждаешь?
Хм...какой слог, экспрессия, глубина мысли....я вот имею смелость признать
что не силен в яве, но почему то еще никто не признался, что не силен в
перле, зато рассуждений...
Yury Kopyl aka hrg | http://id.totem.ru |
"Если ты плюнешь на коллектив — коллектив утрется,
но если коллектив плюнет на тебя — ты утонешь" (С)Баралгин
VladD2 -> "Re[18]: Помогите мотивировать начальство" :
iT>> Кстати, perl-гуру тебе килотонну таких фишек набросает. iT>> Вот только ты скажешь, что это ужас, а не фичи, а он — что это кул iT>>
V> Видимо я плохо знаю Перл, но я низнаю ни одной вещи из Перла которой V> нет в Яве. Просто многие встроенные в Перл фичи в Яве вынесены в V> библиотеки. Те же хэш-таблицы или регексы...
а слабо постоить объект на скаляре, массиве, регеспе или filehandler?
Yury Kopyl aka hrg | http://id.totem.ru | "Спам придумали боги в отместку за
наши молитвы."
Здравствуйте, hrg, Вы писали:
hrg>Хм...какой слог, экспрессия, глубина мысли....я вот имею смелость признать hrg>что не силен в яве, но почему то еще никто не признался, что не силен в hrg>перле, зато рассуждений...
У меня есть небольшой опыт в прле, который я решил не продолжать. Времени я на него потратил довольно много, а толку никакого. Питон тот же мне пошел гораздо быстрее и проще.
Здравствуйте, hrg, Вы писали:
hrg>VladD2 -> "Re[18]: Помогите мотивировать начальство" :
iT>>> Кстати, perl-гуру тебе килотонну таких фишек набросает. iT>>> Вот только ты скажешь, что это ужас, а не фичи, а он — что это кул iT>>>
V>> Видимо я плохо знаю Перл, но я низнаю ни одной вещи из Перла которой V>> нет в Яве. Просто многие встроенные в Перл фичи в Яве вынесены в V>> библиотеки. Те же хэш-таблицы или регексы...
hrg>а слабо постоить объект на скаляре, массиве, регеспе или filehandler?
Ну это вообще космический улет. Ты еще скажи про такое
($as,$sd,$sf) = superfunction($super_parameter)
или про такое
sub superfunction
{
my($guid)=@_;
Вопрос не в том, какие конструкции есть в языке, а в том, какую программу или комплекс ты сможешь создать на нем. Что такое невозможно принципиально на Жава, что можно на перле ?
VladD2 -> "Re[10]: Помогите мотивировать начальство" :
V> Здравствуйте, hrg, Вы писали:
hrg>> При правильном употреблении — очень даже. Т.е. понятие hrg>> классического overload'а для функций — нафиг не нужно.
V>
V> Ты эту глупось еще в форуме по С++ скажи... вот смежу то будет.
Изречение было про perl. Причем тут С++ — непонятно. Но надо признать,
квотишь ловко
Plutonia Experiment -> "Re[14]: Меня не понимают" :
PE> Здравствуйте, hrg, Вы писали:
hrg>> ок. Жду реализаций этой же функциональности на других языках.
PE> Будет, только скажи, что ты хочешь уточнить. Если размер кода, то PE> приводить код лишнее.
Кого интересует размер кода в наши годы?
Yury Kopyl aka hrg | http://id.totem.ru | Все вышесказанное является моим
личным мнением и может быть использовано против вас
Здравствуйте, _vovin, Вы писали:
_>Указанный случай неявно вводит следующие ограничения: _>1) Разные версии классов не взаимодействуют между собой.
И что в этом такого? Было бы довольно парадоксально, если бы два экземпляра одного класса работали по разному. Поэтому разные версии одних и тех же классов друг с другом не взаимодействуют.
_>2) Разные версии классов не взаимодействуют с другими классами, которые могут быть загружены позже и у них будет одинаковая версия.
Это ещё почему? Тут все нормально. Два вэб приложения разных версий используют одну и ту же библиотеку.
_>3) Не требуется хранить экземляры классов в памяти, которые при обновлении версии должны быть автоматически конвертированы в новую версию.
Мда. Про такое пока не слышал. Но если мы с тобой об этом не знаем, то не значит что такого не существует.
_>Если бы в реальных приложениях было так просто, я бы не встречал ошибок несовпадение версий классов.
У нас в проекте тоже раньше были, пока мы не ввели нормальный менеджмент классов.
_>При разработке типичного веб-приложения требуется и взаимодействие и хранение экземпляров классов, поэтому перегружать сервер требуется постоянно.
Что ты понимаешь под сервером? Если само вэб-приложение, то да. А если веб-сервер, то нет.
_>Все началось с утверждения о кривых руках. Теперь оказалось, что многое реализовать нетривиально (значит не реализовано сейчас?).
Ты все перефразируешь. Во-первых не многое а только взаимодействие классов разных версий.
А слово "нетривиально", не обозначает, что реализации до сих пор не существует. Оно обозначает, что без дополнительных средств (библиотек, либо разработанных тобой инструментариев) ты этого организовать не сможешь.
_>Так что давайте заберем свои слова обратно.
Ну, уж дудки. В кои веки собрался пофлеймить!
А ещё меня задело необоснованное обвинение в сторону Sun.
Очень аргументированно опротестовал.
" :
