Стандартный набор OCaml'щика ;)

2 NikS: Вы несколько перегибаете палку и уходите в эмоции (и переходите на личности). Очень, знаете, не хотелось бы однажды почувствовать сожаление, что я нахожусь в одном лагере с Вами...

Не пойму я. Титиретик AC (мала-мала знающий Java) говорит, что в Java можно сделать кучу ошибок.

А я, грешный, каждый день работающий на Java, таких ошибок просто не делаю.

Вот это номер! Еще недавно singletons были - и вот их их уже нет. А что возврашает Toolkit.getDefaultToolkit()? Да нет, коллега. singletons у нас есть. И мы их любим. Только их воспринимать нужно иначе (и спокойнее) - не как часть состояния instance. И _сознательно_ идти на то, что некоторые классы не будут соответствовать JavaBeans. А при чем тут anonymous inner classes - я, извините, даже не понял...

>> Вы несколько перегибаете палку и уходите в эмоции

Просто достали высоколобые теоретики. Будут указывать, как мне правильно программировать, да какой язык выбирать & etc..

Это не повод терять лицо.

>> Toolkit.getDefaultToolkit()

This class is the abstract superclass of all actual implementations of the Abstract Window Toolkit. Subclasses of Toolkit are used to bind the various components to particular native toolkit implementations.

Toolkit не является JavaBeen. А поймать хотят как раз на singleton в JavaBean.

Кроме того SWT (в Eclipse) имеет несколько другую архитектуру.

>> А при чем тут anonymous inner classes - я, извините, даже не понял...

Гарантия создания одного экземпляра класса.

Niks нашинский человек, хотя иногда и говорит, что C# это круто 8-)))
То, что функционлаьщики достают - это правда. На этом сайте сконцентрировалось куча альтернативщиков всех мастей. поэтому здесь для них самое место, чтобы проталкивать свои трижды никому ненужные языки - может какой-нибудь неофит LOR'a на это дело западет, а там глядишь и не так одиноко будет.
Нет, наше дружное Java Community не сломить! 8-)

>> хотя иногда и говорит, что C# это круто 8-)))

Круто то, что Eclipse (написанный на Java!) запускает C#;))

А, скажу честно, я не люблю C# за передачу сообщений примитивным типам данных. А также за препроцессор, за возможность прямой работы с памятью, отсутствие стандартной графической и middleware среды & etc..

Niks, а ты apache Axis смотрел? я сейчас его начал использовать - очень прятные впечатления. По удобству скоро догонит и перегонить MS-овский аналог.

<который даже "singelton" без ошибок написать не может. >

Открыл GoF -- SingLeton. Тем более, никто и не обещал, что вам напишут _классический_ синглетон. Целью моего примера было продемонстрировать, что возможен _некорректный_ доступ даже к объекту, у которого все поля закрыты тра-та-та, через некий глобальное окружение -- то есть, проиллюстрировать возможность побочного эффекта. То есть, возможно изменения состояния, которое специфицировано _не_явно_. Это и есть ПЭ.

< Статика запрещена.>

Какая _именно_ статика? В коде нельзя использовать _ни_один_ класс с со статическим методом или со статическими членам?

<В Design Patterns думать нада! >

В Desing Patterns -- думать? Да господь с вами.

<А AC даже класс типа "синглелтона" без ошибок написать не может. >

Продемонстируйте эти ошибки. Или переставайте нести бред.

<Нет там никаких singletons. >

Нет?? А вы мне цитату,_явно_ запрещающую использование таких классов, не приведете?

В итоге, резюме -- если _полностью_ _АДМИНИСТРАТИВНО_ (sic! поскольку соответствующих языковых средств нет) запретить использование class methods и class variables, то проблема ПЭ действительно сходит на нет, поскольку поскольку _неявно_ изменить среду становится невозможным. Однако наши уважаемые офисные программисты способны на все, что угодно -- кричать про анонимные классы, нести чушь о том, что в "яве нет синглетонов", ссылаться на свои "монографии", рассказывать про посещенные ими ИБМ-центры, взывать к Гамме и работать компилятором -- на все, кроме того, чтобы сделать этот _элементарный_ вывод. Мораль -- господам офисным программистам и авторам заборостроительных монографий следует меньше писать, и больше читать.

"В Java есть anonymous inner classes. Нет там никаких singletons". Ваши слова? Аккуратнее надо с языком. Поэтому и говорю - не кипятитесь.

Итак, язык Java допускает singletons. Рекомендации JavaBeans - нет. Сойдемся на этом? Даже если SWT имеет другую архитектуру - использование singletons в Java полезно и эффективно (оговорки прилагаются).

Гарантией создания одного экземпляра является приватный конструктор, private static MyClass theInstance; и метод public MyClass getInstance() (возможно, synchronized). А anonymous inner classes - это, как я понимаю, sun рекомендует несколько для других вещей. Создание единственного экземпляра - это своего рода побочный эффект этих классов:) Кстати, большинство (или даже все?) вариантов singleton, которые я видел, стрОилось на именованных подклассах со вполне себе публичными конструкторами. Другое дело, что в api эти классы не упоминались. А был просто BaseClass.getInstance(), который при первом вызове смотрел куда-то в конфигурацию, находил дочерний класс, конструировал и выдавал. Рекомендации лучших собаководов.

>> Продемонстируйте эти ошибки.

С удовольствием:

class E {
public static changeE() {     //!!!!
s = "changed";
}
public static String getE() {
return s;
}
static String s = "ok";
}

class Closed {
public Closed() {}
public setX(int XV) {      // !!!!!!
E.changeE();
x = XV;
}
public int getX() {
return x;
}
int x;
} 

>> что в "яве нет синглетонов"

В JavaBeans нет singleton'ов - не надо передергивать.

>> Итак, язык Java допускает singletons. Рекомендации JavaBeans - нет.

Вы правы.

<public static changeE() { //!!!!>
У вас амнезия? Полечитесь, я уже давно ссылаюсь на другой код. Я то я вам напомню casting и численные методы. Как-то мы про них позабыли.

<В JavaBeans нет singleton'ов - не надо передергивать.>
И что, если я напишу singleton, компилятор будет ругаться?

<>> что в "яве нет синглетонов"

В JavaBeans нет singleton'ов - не надо передергивать.
>

Читаем сообщение от NiKS (20:42:57.974)
"В Java есть anonymous inner classes. Нет там никаких singletons...."

Немедленно возникает вопрос -- это какая же бредятина написана в монографиях автора, который просто-напросто неадекватен -- несет чушь и элементарно не помнит, что писал полчаса назад, зато очень успешно придирается к чужим int'ам.

>> И что, если я напишу singleton, компилятор будет ругаться?

Нет, не будет при правильном синтаксисе)

>> Я то я вам напомню casting >>>> "Как правило, такие преобразования используются по отношению к объекту специализированного класса, чтобы _присвоить_ его значение _объекту_ более общего класса" (выделено мной). Отдохните. >>>>

Так кто из объектов же есть объект более общего класса НelloHome (for ex.) или PortableRemoteObject? Отдохните.

>> неадекватен -- несет чушь

Да, метод, не возвращающий значение - это сильно!

<Нет, не будет при правильном синтаксисе) >

Ну, а тогда вообще о чем разговор? Если не будет, то проблема ПЭ в Java и в Javabeans существует. Точка.

<Так кто из объектов же есть объект более общего класса НelloHome (for ex.) или PortableRemoteObject? Отдохните. >

Извиняюсь, у вас проблемы -- раз вы видите, что хотите увидеть, а не то, что написано? С_чего_вы_решили_, что моя фраза имела _хоть_какое_то отношение к вашему примеру с какими-то VeryLongClassName?
Или вы посмеете оспорить, что операндом и результатом операции cast являются _объекты_, и преобразовываем мы именно что _объекты_? В чем и был смысл вышеприведенной цитаты, и выделены были слова "объект".
Вы почему-то совершенно неадекватно (опять!) восприняли ее, решив, что акцент там делается на типах. Может, вам лучше на Мальту -- отдохнете от инженегрии.

<Да, метод, не возвращающий значение - это сильно! >

Теперь и я попридираюсь к словам. Не "не возвращающий значение", а "не специфицирующий _тип_ возвращаемого значения". Методов, не возвращающих значения -- навалом, они имеют тип void. Так что же написано в монографиях у автора, который не понимает разницы между значением и типом?

AC -- вы молоток. NikS в этом треде показал себя полным мудаком, в чем я и раньше его подозревал. Я, в принципе, не являюсь горячим сторонником функциональных языков, но меня просто поражает метод ведения спора господами явистами :)) Хвастаться каким-то сраным брейнбенчем (я как-то по молодости упомянул при собеседовании на работу XX своих сертификатов - мне, мягко говоря, в усы улыбнулись :)), упоминать человеку синтаксические, а не логические ошибки в коде (достойно школяра, не более), пинать за якобы неправильное слово "синглетон" и в следующем же посте писать его точно так же; сплошь и рядом сворачивать разговор на любимую тему, в которой он типа рубит больше; хвастаться какими-то с пальца отсосанными монографиями и фамилиями челов, которые он вычитал в обзорах прессы... мда...

"Ну, я вас умоляю!". Не стОит методы ведения спора, применяемые господином NikS, считать свойственными всем защитникам Java. Хотя, справедливости ради надо отметить, что господин АС тоже не всегда вел спор корректно (не будем опускаться до "он первый начал" - это к обеим сторонам).

Однако говорилось, что OCaml GC более быстрый чем в любой жабе. А в Java при вызове какого-либо метода, который изменяет состояние других объектов и данного объекта, можно ли предсказать возвращаемый результат в любой момент времени работы программы ?

О слабой пригодности Java для реализации численных методов интересно написано здесь:

http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf

правда, статья довольно старая и все могло с тех пор измениться к лучшему.

--

SVK

2Niks: как ты думаешь Гослинг читал Гослинга?

PS: чтобы понять рекурсивность сначала нужно понять рекурсивность.

Думаю, что м..... - это ты с AC, который просто подкинул забесплатно NikSу кучу идей, которые он будет использовать в своих целях. NikS просто спровоцировал AC. "Монографий" у него NikSа нет, но коммерческие книжки он продавать успешно ухитряется:

http://www.linuxshop.ru/?page=about&what=books&item=297

Статья действительно интересная. Единственное - если я не могу оценить верность выкладок про числовые форматы (никогда не занимался этим вопросом), но про operator overloading - я скажу Гослингу большое спасибо. С перегрузкой операторов в С++ можно наворотить такого (особенно с присваиванием), что потом чорт ногу сломит. Не только нечитаемо и неэффективно, но и просто неверно. Одна дама, помнится, написала присвоения для немаленького класса (с конструкторами и пр.), забыв поставить & перед аргументом. Вот веселуха была... Так что - долой. Все остальное выглядит разумно и обоснованно (хотя, повторяю, я не спец в этом узком вопросе).

Да, статья не очень древняя. С тех пор в java.math ничего не менялось. Сан развивает жабу не в ту сторону. Может, оно и правильно. Для "этого" пусть используют ocaml и пр. языки спец. назначения... Хотя несоответствие ieee 754 - это нехорошо, надо бы вылечить...

Да, и еще. Лично Гослинг по этому поводу думает так:

http://java.sun.com/people/jag/FP.html

Не совсем то, что у Mr.Kahan, но проблема признана существующей. И даже http://java.sun.com/pr/1998/03/pr980323.html. Другое дело, что воз, как мне видится, и ныне там... Ну не разорваться им - они на enterprize market прут. Другие приоритеты и задачи.

>> Да, статья не очень древняя.

В 1998 был HotSpot? Не надо "ля-ля"! Я хоть и не Brainbench master, но знаю, что не был.

У функцианальщиков осеннее обострение. Достали своими никому не нужными недоязычками.

Java - ruleZZZ forever!

При чем тут HotSpot? Оба автора пишут об изменениях в API, байткоде, спецификациях языка. Язык, процессируемый HotSpot в отношении математики - не имеет этих изменений. API java.math.* и java.lang.Math не менялись с 1.2. И язык не менялся (в этой области, я не говорю про всякие assert). И байткод.

Так, кажется скоро меня запишут в лагерь противников жабы. Хотя, ей, богу, я ее очень люблю...

>> запишут в лагерь противников жабы

Противник, однозначно противник. Еще один провокатор. Запомни, Java рулит. Как ты запихнешь в JDBC DECIMAL?

<Одна дама, помнится, написала присвоения для немаленького класса (с конструкторами и пр.), забыв поставить & перед аргументом.>

Мда, то, что в стандарте допустили assignment operator с нессылочным типом аргумента -- это, действительно, достаточно странно....
С другой стороны, перегрузка операторов иногда позволяет записывать какие-то конструкции более "наглядно" (например, операции в пользовательской арифметике, например, real -- как сделать красиво без перегрузки?), а перегрузка вывода в поток -- вообще замечательно, без перегрузки поточная библиотека была бы существенно менее удобной. Было бы странно разрешать перегрузку одних операторов, и не разрешать других (это ж не Java, где для строки + перегружен, а больше ни для кого нельзя). Поэтому она есть.

Жава рулит не "вообще". А для конкретных классов задач. Можно обсуждать список этих классов. Можно пытаться его расширять (что и делает Сан - но не очень активно, ему сильнее хочется оттяпять побольше рынка в классе enterprize app). Но всегда будут задачи, где есть решения лучше (эффективнее, удобнее для специалистов в предметной области и т.д). Не надо фанатизма, коллеги.

А в чем проблема? setBigDecimal уже не годится? Или я не понял вопроса.

>> С тех пор в java.math ничего не менялось.

Так вот запомни, Brainbench, что в java.math лежат классы BigDecimal и BigInteger, a IEEE754 лежит в java.lang.Math.

Эта "наглядность" очень провоцирует. Люди перестают думать об эффективности и правильности кода, о тех самых побочных эффектах. Переопределят "+" как попало - и давай его применять. А то, во что это выливается в реальном коде - никого не интересует. Тут психологический барьер - при вызове функции программер, хоть на секунду, задумывается о стОимости этого действия. Если же он пишет "+" (или хуже того "=") - он вообще не знает, к чему это приведет (и - что хуже - не задает себе этого вопроса). Причем для "=" даже не известно, то ли просто данные двоично скопируются, то ли будет произведена какая-то бурная деятельность... (вывод на экран, парочку пакетов в сетку, просчитана сложная функция). Мне кажется, этот психологический барьер полезен в чисто методическом смысле. А Вам?

Да, оператор "+" для строки - странное место. Это правда.

Они (эти классы) были давно. И полной совместимости не дают. Посмотри на статью самого Гослинга (ссылка приведена мной ниже). Что из этого реализовано? Ничего. Даже sqrt(float) нет. Т.е. 754 реализован не полностью. Как и в 1998.

Да, я понял - Вам не понравилось, что я забыл добавить к java.math.* java.lang.Math. Я думал, из контекста было понятно, что под java.math я имел в виду весь мат. аппарат жабы. Если нет - извиняюсь за неточность.

Я тебе про java.math.BigDecimal говорю.

Щас все прям все в Java Community удавятся, что в Java sin от float не существует. Мне на это три кучи... Если хочешь чего посчитать, то возьми интеловый фортран нахаляву.

<Мне кажется, этот психологический барьер полезен в чисто методическом смысле. А Вам?>
А мне. А мне кажется, что преимущества перегрузки операторов (наглядность, в первую очередь для "арифметики", возможность писать
наглядный параметризованный код, возможность expression templates, красивая поточкная библиотека, etc.) примерно уравновешиваются тем же самым недостатком -- отсутствием наглядности. Поэтому к перегрузке операторов я подхожу согласно известному принципу про множественное наследование и парашют. Плюс -- стоит ее реализация что-нибудь компилятору? Нет. Дает ли перегрузка сама по себе оверхэд на рантайме? Нет. Поэтому, я, в общем-то, сторонник ее наличия.

Я Вас умоляю - почитайте ту статью Гослинга, которую я привел ниже. sqrt(float) - это оттуда! И много других вещей, полезных для математики, которые хорошо бы добавить|поменять.

А вот последняя фраза - в точку. Как ни обидно, но сегодня именно "возьми фортран". А ведь совсем небольшими модификациями (опять же, см. Гослинга) можно было сделать жабу существенно более пригодной для вычислистики. Но - приоритеты, приоритеты...

ЗЫ Да, я точно помню, что с анонимами на брудершафт не пил...

Кстати, AC, если ты у нас такой парень умный, то ответь мне, если в ocaml поодержка CORBA.

Только ты меня г....ом типа mico или ORBit не грузи, а расскажи про персистентый сервис, транзакции, сервис сообщенй.

* To: caml-list@inria.fr * Subject: CORBA access from OCaml * From: Friedman Roy <roy@cs.technion.ac.il> * Date: Fri, 26 Feb 1999 14:28:22 +0200 (IST)

Hi everyone,

Has anyone written a CORBA interface to OCaml. Actually, the best thing for me would be something that interoperates with the new IIOP based java RMI. I might be willing to do some porting of existing code that does most of what I need. However, in either case it has to be freely distributeable (GPL is fine.)

Thanks,

Roy

Это что запостил "засланный казачок"?

Да, я понимаю Вашу позицию. Наверное, Вам в жизни везло - Вам не приходилось догадываться, что стоИт за всеми этими "+" и "=" в чужом кода (и ловить побочные эффекты типа вызовов криво написанных конструкторов копирования). Что ж, дело вкуса.

И, кстати, Вы никогда не мерили, насколько любимые Вами потоки медленнее обычного fprintf (я уже не говорю про write)? Мы как-то меряли - жуткие результаты получились. Сейчас, может, оно получшело - может, кто-нибудь померяет, расскажет?

Всего,

Сергей

<Только ты меня г....ом типа mico или ORBit не грузи, а расскажи про персистентый сервис, транзакции, сервис сообщенй. >

Есть биндинги для COM. Если ли вышеуказанное -- честно скажу -- не знаю, может есть, а может и нет, мне этим пользоваться в ocaml не приходилось. Те, кому это нужно, могут воспользоваться языками/окружениями, в которых все это уж точно есть и отработано -- той же джавой.
Я, кстати, никогда и не отрицал, что для задач "бизнес-программирования", где вся эта "байда" нужна, Java -- чуть ли не самая подходящая среда.

Урря, договорились! Тост: "За разделение обязанностей". "Language всякие нужны, language всякие важны". АС, пьем?

Только что заметил - вышли на первое место по количеству мессаг. По-моему, скриншот еще никогда не достигал на LOR такой популярности:)

<Наверное, Вам в жизни везло - Вам не приходилось догадываться, что стоИт за всеми этими "+" и "=" в чужом кода >

Наверное -- видеть вывод на дисплей в перегруженном + мне как-то не доводилось:) -- обычно я наблюдал разумную перегрузку. С assignment все вообще просто -- это оператор, который для нетривиальных классов перегружается почти всегда, поэтому и проблем с его восприятием никаких.

<И, кстати, Вы никогда не мерили, насколько любимые Вами потоки медленнее обычного fprintf (я уже не говорю про write)?>

Ну вы даете -- сравнивать с write. А вы никогда не "мерили", насколько потоки "безопасней" того же fprintf? Далее -- оверхэд на потоки в нормально реализованных стандартных библиотеках минимален.
С++ -- это как раз такой язык, который ничего не навязывает -- хочешь (это не вам, а безличная форма:)) понятности, удобства и безопасности с минимальным оверхэдом -- пользуешь потоки, хочешь побыстрее и попривычнее -- пользуй fprintf.

>> Есть биндинги для COM

Какого ты тогда сюда приперся? Иди учи неофитов жизни на windoZe.org.ru

>> честно скажу -- не знаю

А ... тогда всех во всех трэдах на этом сайте ты поучаешь?

>> мне этим пользоваться в ocaml не приходилось

А мне твоим дерьмовым ocamloм пользоваться не приходилось. Тебе, мусье, уже русским языком пояснили.

"То, что функционлаьщики достают - это правда. На этом сайте сконцентрировалось куча альтернативщиков всех мастей. поэтому здесь для них самое место, чтобы проталкивать свои трижды никому ненужные языки - может какой-нибудь неофит LOR'a на это дело западет, а там глядишь и не так одиноко будет."

>> где вся эта "байда" нужна

Твоя функцианальная байда тем более в реальной жизни не нужна.

Господи, что это защитники Жабы такие хамоватые нонче попадаются?...

Кстати, АС, "байда" по отношению к сетевым возможностям архитектуры Java - как-то неуважительно. Хотите, чтобы Ваш язык уважали за его фичи - извольте уважать наши.

<тогда всех во всех трэдах на этом сайте ты поучаешь? >

Я ж не поучаю, как пользоваться CORBA в ocaml, и, если уж говорю о чем-либо, то знаю, о чем. В отличие от тебя.

<А мне твоим дерьмовым ocamloм пользоваться не приходилось. Т>

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

<На этом сайте сконцентрировалось куча альтернативщиков всех мастей. поэтому здесь для них самое место, >

Ха, совок сдох 11 лет назад, а совки остались -- все им бы стройными рядами вместе ходить. Линукс, Java, комсомол! Учение джава истинно, потому что оно верно!

<Твоя функцианальная байда тем более в реальной жизни не нужна. >

Если тебе в твоей реальной жизни что-то не нужно, из этого никак не следует, что это никому не нужно. Обычно лет с 14 это уже понимают. У тебя задержки развития?

А перегрузка "+" никаких ограничений не ставит. Можно делать все, что угодно. Это как JavaBeans: можешь - держи себя в руках, не можешь - не держи.

Ну, с write, я, может, погорячился (хотя, помнится, потоки и на двоичный вывод претендуют). Но проблем у fprintf я не знаю (не надо про sprintf, ладно?). Расскажите, плиз. И все-таки - давайте на досуге померяем fprinf vs ostream?

<"За разделение обязанностей". "Language всякие нужны, language всякие важны">

Я с вами полностью согласен.

<Кстати, АС, "байда" по отношению к сетевым возможностям архитектуры Java - как-то неуважительно.>

В таком случае, извините. Просто для меня это слово не несет негативной нагрузки. Если для кого несет -- я неправ. Все это, естественно, очень важно и нужно.