Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
Что на ваш взгляд является главным недостатком Java?
Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
Вообщем, прошу к барьеру
21.11.05 20:21: Перенесено модератором из 'Священные войны' — Kupaev
Здравствуйте, Gregory_krovosos, Вы писали:
G_>А давайте поразмышляем на тему сравнения платформы .NET и Java в свете выхода Java 1.5 Tiger? G_>(про нововведения в Java 1.5 тут можно почитать — http://pt.sun.com/javaondemand04/pdf/J2SE-Tiger.pdf)
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
G_>Что на ваш взгляд является главным недостатком Java?
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
G_>Вообщем, прошу к барьеру
И началась битва великая,
И полились реки кровавые,
И полетели головы горячие
Со свистом с широких плеч.
Только в голову бьющимся,
Не пришёл вопрос отнюдь не праздный:
"А зачем вся эта битва жестокая ?"
(с)
G_>>Вообщем, прошу к барьеру
BiТ>И началась битва великая, BiТ>И полились реки кровавые, BiТ>И полетели головы горячие BiТ>Со свистом с широких плеч. BiТ>Только в голову бьющимся, BiТ>Не пришёл вопрос отнюдь не праздный: BiТ>"А зачем вся эта битва жестокая ?" BiТ>(с) BiТ>
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
Любители ли вы портвейн так как люблю его я.
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
А оно надо? Что-то win до сих пор это никак не мешало...
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
enumerations, fixed, using, unsafe, Interop...
G_>Что на ваш взгляд является главным недостатком Java?
EJB Ах, да... еще создание GUI под Windows..
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний. G_>Вообщем, прошу к барьеру
А если серьезно, то Java определенно более сильна в случае Enterprise-level систем.
Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек...
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
В яве нет:
1. using-а
2. Делегатов.
3. Структур (вэлью-типов определяемых пользователем).
4. Области видимости internal и pronected internal.
5. Их дженерики не дают выигрыша в скорости и немогут быть переданы в другую сборку.
G_>Что на ваш взгляд является главным недостатком Java?
Sun. У них маркетинг хуже и денег в Яву они вкладывают мнеьше.
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
Ну, число компаний уже немалое. По переностимости есть Моно, то это конечно далеко не дотнет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G_>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
J>
J>Любители ли вы портвейн так как люблю его я.
Речь как раз не о предпочтениях/традициях, а о реальных возможностях этих систем.
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
J>А оно надо? Что-то win до сих пор это никак не мешало...
RB>Сама постановка вопроса
G_>>... чего есть в C# + .NET такого чего нет в Java?
RB>ставит Java на место догоняющего. Это характерно, или так получилось???
Именно. Ведь .NET появился позже и обязан был по этой причине дать что-то новое.
G_>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>enumerations, fixed, using, unsafe, Interop...
Enum в 1.5 появились.
Извините, я с шарпом не так хорошо знаком.
fixed — ?
using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это?
unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения.
Interop -?
G_>>Что на ваш взгляд является главным недостатком Java? kuj>EJB Ах, да... еще создание GUI под Windows..
Имеются в виду тормоза Swing? Есть Eclipse.
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний. G_>>Вообщем, прошу к барьеру kuj>А если серьезно, то Java определенно более сильна в случае Enterprise-level систем. kuj>Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек...
S>> А вот скорости нужно сравнить
G_>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент!
Это пример недостатка. Но никак не аргумент. Просто непонято почему в тигре они не внедрили структуры.
А если внимательно почитаешь ту ветку то разница может быть весьма сущщественаа на многих алгоритмах.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Gregory_krovosos, Вы писали:
G_>fixed — ?
Блокировать класс от перемещения в памяти сборщиком мусора. Нужно для того чтобы обойтись без маршалинга при общении с неуправляемым кодом.
G_>using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это?
Нужно. Ждать пока сборщик вызовет финалайзеры для некоторых ресурсов (например файловые хендлы или соединение с БД) неприемлемо.
G_>unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения.
Нет, возможность явного использования указателей и адресной арифметики. Обычно используется совместно с fixed.
G_>Interop -?
А вот это как раз и есть взаимодействие с нативным кодом.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>>enumerations, fixed, using, unsafe, Interop... G_>Enum в 1.5 появились.
А поддержку со стороны библотек тоже сделали? G_>fixed — ?
Лазейка на низкий уровень. Позволяет использовать адресную арифметику и запретить проверку на выход за границы массива.
G_>using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это?
Чисто ради удобства. В finally можно забыть закрыть системный ресурс, с using это происходит реже.
G_>unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения.
Нет. unsafe используется обычно в паре с fixed.
The unsafe keyword denotes an unsafe context, which is required for any operation involving pointers.
G_>Interop -?
Для вызова функции из внешних dll, создания COM, ActiveX объектов. В том числе предоставляет средства для маршалинга.
G_>>>Что на ваш взгляд является главным недостатком Java? kuj>>EJB Ах, да... еще создание GUI под Windows.. G_>Имеются в виду тормоза Swing? Есть Eclipse.
Да это я в шутку. Сейчас GUI на Java вполне неплох. Даже swing`овый.
G_>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний. G_>>>Вообщем, прошу к барьеру kuj>>А если серьезно, то Java определенно более сильна в случае Enterprise-level систем. kuj>>Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек... G_>Ну так и у кого он лучший?
Это из серии: "в какой стране самые красивые девушки". Вопрос, на который физически не возможно дать объективный и однозначный ответ.
S>> А вот скорости нужно сравнить G_>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент!
Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
Reflection.Emit, то есть возможность генерации кода в run-time
из того, что я слышал — генерики в Яве эмулируются с помощью reflection'a, что исключает всякий выигрыш в скорости от их использования
Здравствуйте, Gregory_krovosos, Вы писали:
G_>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
J>>А оно надо? Что-то win до сих пор это никак не мешало...
G_>Windows завоевало клиента, но не сервер.
S>>> А вот скорости нужно сравнить G_>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться
с применением класса вместо этой структуры.
S>>>> А вот скорости нужно сравнить G_>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
G_>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>с применением класса вместо этой структуры.
На вскидку — плотные вычисления над большими матрицами комплексных чисел. .
G_>>fixed — ?
AVK>Блокировать класс от перемещения в памяти сборщиком мусора. Нужно для того чтобы обойтись без маршалинга при общении с неуправляемым кодом.
G_>>using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это?
AVK>Нужно. Ждать пока сборщик вызовет финалайзеры для некоторых ресурсов (например файловые хендлы или соединение с БД) неприемлемо.
G_>>unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения.
AVK>Нет, возможность явного использования указателей и адресной арифметики. Обычно используется совместно с fixed.
G_>>Interop -?
AVK>А вот это как раз и есть взаимодействие с нативным кодом.
Насчет автоматического вызова финалайзера — это неплохая возможность, но она уже не так значима как, скажем, в C++.
Все остальное, как я понимаю, есть мудреные технологии, которые позволяют юзать COM-объекты и найтивный код.
Вообще-то, как я понимаю Java и .NET создавались как раз чтобы избежать этого... В любом случае, в Java есть JNI. Он дает возможность
писать платформенный код.
G_>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>с применением класса вместо этой структуры.
Здесь дело не в том, что нельзя решить а в эффективности использования в массивах
1. Более быстый доступ (без лишней ссылки)
2. Ипользование DDR памяти с фоновой подкачкой, при использовании массива попадает только ссылка, и при больших объемах при не попадании в кэш процессора доступ в 10 раз медленнее
3. Экономия памяти. В Net под объект дополнительно выделяется 8 байт (ссылка на VMT, SincBlockIndex)
4. Не нужно ЖЦ следить за объектом, отсутвие write Barier. http://www.rsdn.ru/Forum/Message.aspx?mid=558877&only=1
G_>>>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>>>enumerations, fixed, using, unsafe, Interop... G_>>Enum в 1.5 появились. kuj>А поддержку со стороны библотек тоже сделали?
Не знаю, есть поддержка нового for(item:collection). Вот пример оттуда:
public enum Suit { spade, diamond, club, heart };
public enum Value { ace, two, three, four, five,
six, seven, eight, nine, ten,
jack, queen, king };
List<Card> deck = new ArrayList<Card>();
for (Suit suit : Suit.VALUES)
for (Value value : Value.VALUES)
deck.add(new Card(suit, value);
Collections.shuffle(deck);
G_>>fixed — ? kuj>Лазейка на низкий уровень. Позволяет использовать адресную арифметику и запретить проверку на выход за границы массива.
G_>>using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это? kuj>Чисто ради удобства. В finally можно забыть закрыть системный ресурс, с using это происходит реже.
G_>>unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения. kuj>Нет. unsafe используется обычно в паре с fixed. kuj>The unsafe keyword denotes an unsafe context, which is required for any operation involving pointers.
G_>>Interop -? kuj>Для вызова функции из внешних dll, создания COM, ActiveX объектов. В том числе предоставляет средства для маршалинга.
Ну, вообщем можно сказать что в C# более продвинутая поддержка наитивного кода?
G_>>>>Что на ваш взгляд является главным недостатком Java? kuj>>>EJB Ах, да... еще создание GUI под Windows.. G_>>Имеются в виду тормоза Swing? Есть Eclipse. kuj>Да это я в шутку. Сейчас GUI на Java вполне неплох. Даже swing`овый.
G_>>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний. G_>>>>Вообщем, прошу к барьеру kuj>>>А если серьезно, то Java определенно более сильна в случае Enterprise-level систем. kuj>>>Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек... G_>>Ну так и у кого он лучший? kuj>Это из серии: "в какой стране самые красивые девушки". Вопрос, на который физически не возможно дать объективный и однозначный ответ.
Здравствуйте, Дарней, Вы писали:
Д>из того, что я слышал — генерики в Яве эмулируются с помощью reflection'a,
Нет, не с помощью рефлекшена конечно. Дженерики там настоящие, просто из-за того что они приняли решение не менять рантайм они не создают специализированных реализаций для value-типов, а вместо этого заворачивают их в типы ссылочные. Отсюда даже дженерик-алгоритмы в джаве будут полиморфными.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Не знаю, есть поддержка нового for(item:collection). Вот пример оттуда:
G_>public enum Suit { spade, diamond, club, heart };
G_>public enum Value { ace, two, three, four, five, G_> six, seven, eight, nine, ten, G_> jack, queen, king };
G_>List<Card> deck = new ArrayList<Card>(); G_>for (Suit suit : Suit.VALUES) G_>for (Value value : Value.VALUES) G_> deck.add(new Card(suit, value);
G_>Collections.shuffle(deck);
Не, это аналог шарпового foreach. Enum это другое, это перечисляемые типы
G_>Ну, вообщем можно сказать что в C# более продвинутая поддержка наитивного кода?
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
У Java из этих двух недостатков есть только один — отсутсвие реальной кроссплатформенности.
Причем вызван он по-моему в основном неспешностью Sun в комплексе с его же схемой лицензирования и сертифицирования.
G_>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>с применением класса вместо этой структуры. S> Здесь дело не в том, что нельзя решить а в эффективности использования в массивах S> 1. Более быстый доступ (без лишней ссылки) S> 2. Ипользование DDR памяти с фоновой подкачкой, при использовании массива попадает только ссылка, и при больших объемах при не попадании в кэш процессора доступ в 10 раз медленнее
Это все довольно спорно. Компилятор может оптимизировать подобные вещи.
S> 3. Экономия памяти. В Net под объект дополнительно выделяется 8 байт (ссылка на VMT, SincBlockIndex)
S>>>>> А вот скорости нужно сравнить G_>>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
G_>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>с применением класса вместо этой структуры.
BiТ>На вскидку — плотные вычисления над большими матрицами комплексных чисел. .
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
VVB>У Java из этих двух недостатков есть только один — отсутсвие реальной кроссплатформенности. VVB>Причем вызван он по-моему в основном неспешностью Sun в комплексе с его же схемой лицензирования и сертифицирования.
В смысле, что мало платформ поддерживается или что неаккуратно поддерживается?
G_>>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>>с применением класса вместо этой структуры. S>> Здесь дело не в том, что нельзя решить а в эффективности использования в массивах S>> 1. Более быстый доступ (без лишней ссылки) S>> 2. Ипользование DDR памяти с фоновой подкачкой, при использовании массива попадает только ссылка, и при больших объемах при не попадании в кэш процессора доступ в 10 раз медленнее
G_>Это все довольно спорно. Компилятор может оптимизировать подобные вещи.
Не сможет он соптимимизировать последовательное расположение. И на таких алгоритмах http://www.rsdn.ru/forum/Message.aspx?mid=635534&only=1
отставание чудовищное. S>> 3. Экономия памяти. В Net под объект дополнительно выделяется 8 байт (ссылка на VMT, SincBlockIndex)
G_>Ну, это несерьезно. Выгоды больше.
S>> 4. Не нужно ЖЦ следить за объектом, отсутвие write Barier. http://www.rsdn.ru/Forum/Message.aspx?mid=558877&only=1
S>>>>>> А вот скорости нужно сравнить G_>>>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
G_>>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>>с применением класса вместо этой структуры.
BiТ>>На вскидку — плотные вычисления над большими матрицами комплексных чисел. .
G_>А почему нельзя это сделать с помощью классов?
Выделение большого количества памяти в куче гораздо более долгий процесс — нежели выделение того же объёма памяти в стеке.
P.S. А ещё лучше — сравните скорость создания больших (2048x2048) матриц с комплексными числами, в первом случае являющихся классами, а во втором — структурами.
Здравствуйте, Дарней, Вы писали:
Д>Reflection.Emit, то есть возможность генерации кода в run-time
В Java на самом деле это тоже есть (В Sun-овской реализации). Т.е можно сгенерировать класс в рантайме и тут же загрузить в JVM. Проблема в том, что эта функциональность скрыта. Видимо, Sun посчитала эту функциональность лишней (и оставила лишь ClassLoader.defineClass, без констант байт-кода и сборщика класса).
Более того, при десериализации это используется. Там какой-то хитрый класс зачем-то генерится.
S>>>> А вот скорости нужно сравнить G_>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом. G_>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>с применением класса вместо этой структуры.
Вопрос в эффективности, а не в невозможности решения.
Здравствуйте, Gregory_krovosos, Вы писали:
S>> 3. Экономия памяти. В Net под объект дополнительно выделяется 8 байт (ссылка на VMT, SincBlockIndex) G_>Ну, это несерьезно. Выгоды больше.
Какой еще выгоды?
S>>>>>>> А вот скорости нужно сравнить G_>>>>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>>>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом.
G_>>>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>>>с применением класса вместо этой структуры.
BiТ>>>На вскидку — плотные вычисления над большими матрицами комплексных чисел. .
G_>>А почему нельзя это сделать с помощью классов?
BiТ>Выделение большого количества памяти в куче гораздо более долгий процесс — нежели выделение того же объёма памяти в стеке.
Т.е. медленнее означает "нельзя"?
BiТ>P.S. А ещё лучше — сравните скорость создания больших (2048x2048) матриц с комплексными числами, в первом случае являющихся классами, а во втором — структурами.
Причем тут — матрица или не-матрица? Ясно, что создание большого объекта в куче займет больше времение чем операция sub esp, <большой_размер_объекта>
S>>>>> А вот скорости нужно сравнить G_>>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом. G_>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>с применением класса вместо этой структуры. kuj>Вопрос в эффективности, а не в невозможности решения.
Странно, отчего это никто не пишет корпоративные системы на ассемблере?
Они же будут намного эффективней!
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Странно, отчего это никто не пишет корпоративные системы на ассемблере? G_>Они же будут намного эффективней!
Использование структур нисколько не усложняет твой код, не делает его менее читабельным, времени на разработку не тратится больше — так что аналогия ИМХО не самая удачная.
G_>>>Это касается принципа работы GC в .NET. В Яве gc работает по-другому.
AVK>>Т.е. к примеру в джаве GC следит за локальными переменными типа int?
G_>Я имел в виду реализацию, она немного другая.
А как это влияет на то что структуры GC не обрабатывает?
BiТ>>P.S. А ещё лучше — сравните скорость создания больших (2048x2048) матриц с комплексными числами, в первом случае являющихся классами, а во втором — структурами.
G_>Причем тут — матрица или не-матрица? Ясно, что создание большого объекта в куче займет больше времение чем операция sub esp, <большой_размер_объекта>
Вы хотели конкретный пример — я его вам дал.
P.S. Топик однозначно превращается во флейм. Вся содержательная часть — разница между последними версиями Java и .NET уже дана в этом топике ранее...
S>>>>>> А вот скорости нужно сравнить G_>>>>>Нууу. Наличие стуктуры, то есть класса, урезанного по функционалу, это вообще не аргумент! kuj>>>>Структура и класс в .NET совсем разные понятия. Структура — value-type — передается по значению. Класс — reference-type — передается по ссылке. Но самое примечательно, value-type зачастую передаются заметно быстрее reference-type. Именно поэтому структуру в .NET ну никак нельзя считать урезанным классом. G_>>>Приведите, пожалуйста, пример задачи, которая решается с применением структуры и не может решиться G_>>>с применением класса вместо этой структуры. kuj>>Вопрос в эффективности, а не в невозможности решения. G_>Странно, отчего это никто не пишет корпоративные системы на ассемблере?
А при чем тут ассемблер? G_>Они же будут намного эффективней!
Весьма сомнительно. Скорее напротив.
Вы лучше объясните, зачем тип, который в большинстве или даже во всех случаях передается по значению, делать ссылочным и передавать, соответственно, по ссылке?
Или вот скажите, зачем делать интернирование строк, если "и так работать будет"?
Здравствуйте, Gregory_krovosos, Вы писали:
G_>>>А почему нельзя это сделать с помощью классов? BiТ>>Выделение большого количества памяти в куче гораздо более долгий процесс — нежели выделение того же объёма памяти в стеке. G_>Т.е. медленнее означает "нельзя"?
А давайте, например, вообще откажемся от использования ОЗУ и все промежуточные данные будем держать на HDD...
Здравствуйте, Gregory_krovosos, Вы писали:
G_>>>>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>>>>enumerations, fixed, using, unsafe, Interop... G_>>>Enum в 1.5 появились. kuj>>А поддержку со стороны библотек тоже сделали?
G_>Не знаю, есть поддержка нового for(item:collection). Вот пример оттуда: G_>public enum Suit { spade, diamond, club, heart };
Речь о другом. G_>public enum Value { ace, two, three, four, five, G_> six, seven, eight, nine, ten, G_> jack, queen, king };
Suit card.face = Suit.diamond;
Сделали?
G_>>>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний. G_>>>>>Вообщем, прошу к барьеру kuj>>>>А если серьезно, то Java определенно более сильна в случае Enterprise-level систем. kuj>>>>Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек... G_>>>Ну так и у кого он лучший? kuj>>Это из серии: "в какой стране самые красивые девушки". Вопрос, на который физически не возможно дать объективный и однозначный ответ. G_>) Ну хотя бы субъективный)
Если субъективно, то я отдаю предпочтение .NET
kuj>Вы лучше объясните, зачем тип, который в большинстве или даже во всех случаях передается по значению, делать ссылочным и передавать, соответственно, по ссылке?
Здравствуйте, Gregory_krovosos, Вы писали:
kuj>>Вы лучше объясните, зачем тип, который в большинстве или даже во всех случаях передается по значению, делать ссылочным и передавать, соответственно, по ссылке?
G_>Ну скорее всего для единообразия.
Да пойми. Я на Шарпе имею скорость приблизительно как на VC++, простоту выше чем на Яве, качественную среду и отладчик, WinForms, ASP.TET и каждый квартал обновляемый МСДН.
Ты же выдвигая предпосылку о том, что можно работать медленно и не удобно спрашиваеш почему другие так не хотят.
Ты лучше сам ответь, а зачем нужна Ява если у нее нет ни одного приемущества?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты лучше сам ответь, а зачем нужна Ява если у нее нет ни одного приемущества?
А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
Здравствуйте, ivanrsdn, Вы писали:
VD>>Ты лучше сам ответь, а зачем нужна Ява если у нее нет ни одного приемущества?
I>А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
Самое мощное средство разработки для .NET — это Visual Studio. Если не считать глюков, то по возможностям вполне прилично.
kuj>>>Вы лучше объясните, зачем тип, который в большинстве или даже во всех случаях передается по значению, делать ссылочным и передавать, соответственно, по ссылке?
G_>>Ну скорее всего для единообразия.
kuj>Что Вы имеете в виду?
То что сказал Полагаю в Яве не хотят плодить сущностей, отсюда только классы + только под управлением GC.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>То что сказал Полагаю в Яве не хотят плодить сущностей, отсюда только классы + только под управлением GC.
kuj>>>>Вы лучше объясните, зачем тип, который в большинстве или даже во всех случаях передается по значению, делать ссылочным и передавать, соответственно, по ссылке?
G_>>>Ну скорее всего для единообразия.
kuj>>Что Вы имеете в виду?
G_>То что сказал Полагаю в Яве не хотят плодить сущностей, отсюда только классы + только под управлением GC.
Не стоит плодить лишних сущностей, но структуры сущность явно не лишняя, а необходимая...
Здравствуйте, ivanrsdn, Вы писали:
I>А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
Мне не кажется что у IBM есть какие-то реальные преимущества перед каким нибудь ВебЛоджиком, ну, да в общем то как я понимаю речь о серверах приложений?
Если так, то тут не все однозначно. Сейчас все движится к распределенке и корпоративности. В частности к Вебу. Тут дотнету нет ранвный. АСП.НЭТ — это лучшее средство для создания серьезных Веб-приложений.
Что касается интегрированных серверов, то их для дотнета практически нет. Есть правда решения отдельных фирм, но эти фирмы не имеют такого веса в мире. Кстати, решения есть и у наших контор. Тот же АВК работает над чем-то вроде WebSphere-ы с человеческим лицом для дотнета.
Но все что есть в WebSphere доступно под дотнетом в качестве отдельных сервисов. Транзации, безопастность и другие сервеисы обеспечиваются КОМ+-ом, веб — АСП.НЭТ-ом. Доступ к данныхм АДО.НЭТ-ом. И так далее...
МС ведет работу над интеграцией всего этого, но опять таки они делают не один сервер приложений вроде WebSphere, а ОС которая будет обеспечивать все необходимые срервисы.
Сейчас в Лонгхорне (новой версии Виндовс) ведется работа над тремя подсистемами:
1. Графической — Авалон.
2. Файловой — WinFS. Собственно это нманого больше чем файловая система. Это система хранения инфомации. Дастаточно сказать, что NTFS будет поддерживать транзакции и фичи обеспечение отказоустойчивости, а хранение данных приложений будет осуществляться в ОО-виде, и храниться они будут в MS SQL Server.
3. Комуникациоонная подсистема — Индиго. Это тже не голый RPC. В Индиго будут поддерживаться все известные на сегодня парадигмы передачи данных (ORPC, сообщения, веб-сервисы). Индиго будет обеспечивать рнанзакции, гарантированную и не очено доставку сообщений, RPC, LPC и т.п. Причем все это будет очень просто и доступно для программиста, так как основные фичи будут задаваться в виде атрибутов и хмл-файлов.
ЗЫ
Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
.NET кажется и сейчас быстрее.
а будущем .NET будет чуть ли не частью ОС, т.е. будет еще быстрее, чем сейчас
G_>Что на ваш взгляд является главным недостатком Java?
для меня — это убогие средства разработки и ущербная докумнтация
сравните средства разработки с VS.2003 и MSDN.
только в jBuilder я нащел что-то удовл. — там документация не просто javadocs.
я потерял ссылку, но это похожие: http://www.jwz.org/doc/java.html http://www.geocities.com/tablizer/javacrit.htm
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности
windows — это достаточно большой мир, чтобы волноватьмя о других платформах.
G_>и поддержки большого числа компаний.
я этого не знаю... я сколько времени на рынкке .NET и сколько Java ?
G_>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
Не хочу начинать обсуждение, но как старый фанат и программист на яве, пытавшийся воспользоваться оной с 1.0.6 и до времени оного, и ддаже (о ужас) всерьез пытавшийся использовать javabeans, могу только выразить свой печальный опыт, что кроссплатформенности реально там нет. В общем что пахало на линуксе не работает на винде и наоборот, вылезают глюки, я уж молчу про всякие j2me, где чуть не под каждую реализацию приходится отдельный проект с обходом их глюков делать...
Так что это не недостаток. по крайней мере с явой не лучше. Увы
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Что на ваш взгляд является главным недостатком Java? G_>Вообщем, прошу к барьеру
Интересно, а почему не устраивают "священные войны" С# и J#, тихо мирно лежащие в одной студии. Дело наверно не в синтаксисе. Ну допустим сделают на Явовой платформе язык с синтаксисом C#, ну и рантайм изменят для новых фичей, от этого она не перестанет быть Явой.
Главный недостаток явы для меня это — кроссплатформенность. Т.к. я на одной платформе тусуюсь. За все надо платить, за кроссплатформенность платят невозможностью оптимизации под конкретную платформу.
В частности вопросик, насколько извратно будет выглядеть в Ява тигер 1.5 подключение обработчика к оконной процедуре (естейственно Виндовой)? Или может вобще никак? Тогда для некоторых реальных задач Ява отпадает.
А так идеи одни и те же у Явы и .NET, отличия только что .NET делал более крупный монополист (в данном случае это хорошо), заточил хорошо под свою платформу, все единообразно, интегрировано, до мелочей продумано, не надо лазить по углам по щелям всякие примочки собирать. И главное этот монополист планирует и дальше тужиться в этом направлении,имеет бурные планы, и считает что только все начинается. А разработчики Явы уже расслабились.
G_>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. _>.NET кажется и сейчас быстрее. _>а будущем .NET будет чуть ли не частью ОС, т.е. будет еще быстрее, чем сейчас
Не уверен, что сейчас NET быстрее. Где тесты?
Думаю, различия в производительности NET и Java минимальны и будут еще уменьшаться,
так как основаны на близких технологиях.
G_>>Что на ваш взгляд является главным недостатком Java? _>для меня — это убогие средства разработки и ущербная докумнтация
Провокационный вопрос: а на чем еще можно разрабатывать .NET кроме VS 2003?
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности _>windows — это достаточно большой мир, чтобы волноватьмя о других платформах.
Для домашних компьютеров — да, но для компаний все не так просто.
G_>>и поддержки большого числа компаний. _>я этого не знаю... я сколько времени на рынкке .NET и сколько Java ?
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
S>Не хочу начинать обсуждение, но как старый фанат и программист на яве, пытавшийся воспользоваться оной с 1.0.6 и до времени оного, и ддаже (о ужас) всерьез пытавшийся использовать javabeans, могу только выразить свой печальный опыт, что кроссплатформенности реально там нет. В общем что пахало на линуксе не работает на винде и наоборот, вылезают глюки, я уж молчу про всякие j2me, где чуть не под каждую реализацию приходится отдельный проект с обходом их глюков делать...
S>Так что это не недостаток. по крайней мере с явой не лучше. Увы
Я, в частности, из-за этого и говорю насчет Java 1.5
Sun все-таки что-то делает в этом направлении.
Здравствуйте, Gregory_krovosos, Вы писали:
AVK>>А как быть к примеру с int?
G_>Примитивные типы — это отдельная сущность, а структуры — те же классы, только на стеке.
S_>Интересно, а почему не устраивают "священные войны" С# и J#, тихо мирно лежащие в одной студии. Дело наверно не в синтаксисе. Ну допустим сделают на Явовой платформе язык с синтаксисом C#, ну и рантайм изменят для новых фичей, от этого она не перестанет быть Явой.
Имелось в виду сравнение платформ.
S_>Главный недостаток явы для меня это — кроссплатформенность. Т.к. я на одной платформе тусуюсь. За все надо платить, за кроссплатформенность платят невозможностью оптимизации под конкретную платформу.
Отчего же нет?
S_>В частности вопросик, насколько извратно будет выглядеть в Ява тигер 1.5 подключение обработчика к оконной процедуре (естейственно Виндовой)? Или может вобще никак? Тогда для некоторых реальных задач Ява отпадает.
В Яве имеется своя оконная библиотека, поэтому подобная задача и не стоит. Разумеется драйвер на Яве не напишешь)
S_> А так идеи одни и те же у Явы и .NET, отличия только что .NET делал более крупный монополист (в данном случае это хорошо), заточил хорошо под свою платформу, все единообразно, интегрировано, до мелочей продумано, не надо лазить по углам по щелям всякие примочки собирать. И главное этот монополист планирует и дальше тужиться в этом направлении,имеет бурные планы, и считает что только все начинается. А разработчики Явы уже расслабились.
В Яве тоже все продумано. С чего Вы решили, что Sun "расслабился"?
Здравствуйте, Gregory_krovosos, Вы писали:
G_>>>То что сказал Полагаю в Яве не хотят плодить сущностей, отсюда только классы + только под управлением GC.
AVK>>А как быть к примеру с int?
G_>Примитивные типы — это отдельная сущность, а структуры — те же классы, только на стеке.
Скорее всего в яве не плодят дополнительных сущностей не потому, что структуры — те же классы, только на стеке, а потому, что ява это больше академический язык и начинающему студенту тяжело будет понять что такое структура, в чем она отличается от класса и почему в других языках появилась необходимость в данной конструкции.
Да и по куче других отличий.
Возьмем те-же делегаты, что проще использовать для обработки событий? делегат или хитрую конструкцию из интерфейса, адаптера и класса наследника адаптера переопределяющего один/два метода. Понятно, что делегат проще, компактнее в записи и т.п. но, для ява программиста это означает, что нужно запомнить еще одну сущность. а это, может не укладываться в учебные планы, да и бедному ява программисту придется выделить лишний кусок своей драгоценной памяти из скудных запасов... отсюда мы и имеем — застой в платформе и цепляние за устоявшиеся стереотипы.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Провокационный вопрос: а на чем еще можно разрабатывать .NET кроме VS 2003?
C# Builder, Delphi 8, #Develop
G_>>>и поддержки большого числа компаний. _>>я этого не знаю... я сколько времени на рынкке .NET и сколько Java ?
G_>Java — с 1995, .NET — с 2001.
Здравствуйте, Silver_s, Вы писали:
S_>Главный недостаток явы для меня это — кроссплатформенность. Т.к. я на одной платформе тусуюсь. За все надо платить, за кроссплатформенность платят невозможностью оптимизации под конкретную платформу.
HotSpot может
S_>В частности вопросик, насколько извратно будет выглядеть в Ява тигер 1.5 подключение обработчика к оконной процедуре (естейственно Виндовой)? Или может вобще никак? Тогда для некоторых реальных задач Ява отпадает.
через JNI, извратно скажете вы? А как будет решена аналогичная задача для FreeBSD с помощью .Net. На Микрософт мир ПО не ограничивается, не все ж скринсейверы пишут, есть вещи и посерьезнее.
S_> А так идеи одни и те же у Явы и .NET, отличия только что .NET делал более крупный монополист (в данном случае это хорошо), заточил хорошо под свою платформу, все единообразно, интегрировано, до мелочей продумано, не надо лазить по углам по щелям всякие примочки собирать. И главное этот монополист планирует и дальше тужиться в этом направлении,имеет бурные планы, и считает что только все начинается. А разработчики Явы уже расслабились.
До мелочей продумано смешно. Тужиться будете скорее вы когда наткнетесь на непреодолимые ошибки в системе, и на процесс развиия повлиять не сможете никак. Помнится был баг в винде с модальными диалоговыми окнами, еще со времен 95-ки, за все это время они так и не захотели его исправить.
Разработчики явы не раслаблялись, наоборот развитие идет полным ходом, вот придет distributed jvm вот тогда и посмотрим, кто круче.
I>А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
Есть мнение, что WebSphere — кусок крайне неаппетитной субстанции. Подтвержденное человеко-месяцами работы и человеко-днями общения с support-ом по поводу той полудюжены критичных багов, которые за упомянутые человеко-месяцы были обнаружены. Мнение на абсолютную истину не претендует. Но лично я к этому... субстанции по возможности стараюсь не прикасаться и другим советую.
Есть также мнение что на момент конца 2005 г. в .net есть все, что необходимо для нормальной работы. И слава богу.
RB>>Сама постановка вопроса
G_>>>... чего есть в C# + .NET такого чего нет в Java?
RB>>ставит Java на место догоняющего. Это характерно, или так получилось???
G_>Именно. Ведь .NET появился позже и обязан был по этой причине дать что-то новое.
В библиотеке классов Java много путаницы. Начинающих знакомиться с Java класс Date просто сводит с ума
На мой взгляд, .NET имеет более продуманную библиотеку классов. Тот самый случай, когда чужой опыт и ошибки были учтены.
Здравствуйте, sergeych, Вы писали:
G_>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
S>Не хочу начинать обсуждение, но как старый фанат и программист на яве, пытавшийся воспользоваться оной с 1.0.6 и до времени оного, и ддаже (о ужас) всерьез пытавшийся использовать javabeans, могу только выразить свой печальный опыт, что кроссплатформенности реально там нет. В общем что пахало на линуксе не работает на винде и наоборот, вылезают глюки, я уж молчу про всякие j2me, где чуть не под каждую реализацию приходится отдельный проект с обходом их глюков делать...
Какой-то у вас печальный опыт. Про j2me я, конечно, помолчу. Но все что я разрабатываю под Win потом уходит на Linux. Есть нюансы при работе с файловой системой, при работе с графикой, c JNI. Но серьёзных и непоправимых проблем лично у меня пока не было.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Ну, вообщем можно сказать что в C# более продвинутая поддержка наитивного кода?
Если учесть, поверх чего работает .Net, то становится понятным, что .Net без хорошей поддержки нативного кода был бы просто не жилец. Так что гордиться такими вещами, как fixed и unsafe, на мой взгляд, довольно глупо. Они не от хорошией жизни были придуманы.
Здравствуйте, Воронков Василий, Вы писали:
I>>А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
ВВ>Самое мощное средство разработки для .NET — это Visual Studio. Если не считать глюков, то по возможностям вполне прилично.
Ребята, да поймите вы, люди привыкшие работать в Idea, работая в VS просто плачут.
имхо, микрософт может не управиться в конкурентное время с платформой
как я понимаю до сих пор нету аналога серверов приложений, а они уже сейчас сами по себе отходят на второй план — посмотрите что делают SAP, Oracle, IBM, BEA и др. (уже) — портал + warehouse + integration broker + app_server- переход к сервисной архитектуре (не путать с веб-сервисами)
в своем сегменте настольных приложений микрософт, безусловно, будет доминировать в будущем, но в корпоративе — сомнения у мну
Здравствуйте, slskor, Вы писали:
S>Здравствуйте, Воронков Василий, Вы писали:
I>>>А есть ли аналоги таких мощных средств разработки для .NET типа WebSphere Application Development (как-то так)? Вопрос без поткола — просто интересуют аналогичные средства для создания крупрных решений, но для .NET. С большой мощностью и интеллектом.
ВВ>>Самое мощное средство разработки для .NET — это Visual Studio. Если не считать глюков, то по возможностям вполне прилично.
S>Ребята, да поймите вы, люди привыкшие работать в Idea, работая в VS просто плачут.
У VS пасширяемая архитектура. Поставь поверх неё ReSharper и плакать не придётся. А впрочем в VS2005 уже есть многие полезные вещи, которые есть в ReSharperе.
Здравствуйте, slskor, Вы писали:
S>Здравствуйте, Gregory_krovosos, Вы писали:
G_>>Ну, вообщем можно сказать что в C# более продвинутая поддержка наитивного кода?
S>Если учесть, поверх чего работает .Net, то становится понятным, что .Net без хорошей поддержки нативного кода был бы просто не жилец. Так что гордиться такими вещами, как fixed и unsafe, на мой взгляд, довольно глупо. Они не от хорошией жизни были придуманы.
G_>>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>>enumerations, fixed, using, unsafe, Interop...
G_>Enum в 1.5 появились.
G_>Извините, я с шарпом не так хорошо знаком.
G_>fixed — ?
G_>using — имеется в виду очевидно использование IDisposable? (а не подключение пакетов?) Этого в Яве нет, но в концепции сборщика мусора нужно ли это?
G_>unsafe — это возможность вызова платформенного кода? Если да — это вроде бы в Яве с рождения.
G_>Interop -?
G_>>>Что на ваш взгляд является главным недостатком Java? kuj>>EJB Ах, да... еще создание GUI под Windows..
G_>Имеются в виду тормоза Swing? Есть Eclipse.
eclipse тут не причем, это библиотека SWT которая работает с native контролами ОС вместо саморисованных в свинге
G_>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности и поддержки большого числа компаний.
ну это щас рано говорить G_>>>Вообщем, прошу к барьеру kuj>>А если серьезно, то Java определенно более сильна в случае Enterprise-level систем.
спорно kuj>>Во всех других случаях можно долго выяснять кто же лучше, но это пустая трата времени, т.к. в общем случае они примерно равны. В итоге все сведется к выяснению у кого же лучший набор библиотек...
G_>Ну так и у кого он лучший?
Проектирование — это искусство, которым нельзя овладеть только с помощью теоретических занятий.
G_>>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. _>>.NET кажется и сейчас быстрее. _>>а будущем .NET будет чуть ли не частью ОС, т.е. будет еще быстрее, чем сейчас
G_>Не уверен, что сейчас NET быстрее. Где тесты? G_>Думаю, различия в производительности NET и Java минимальны и будут еще уменьшаться, G_>так как основаны на близких технологиях.
согласен, с оговоркой что .NET гарантированно будет лучше вписывается в последующие винды
G_>>>Что на ваш взгляд является главным недостатком Java? _>>для меня — это убогие средства разработки и ущербная докумнтация
G_>Ну, чем же JBuilder или Visual Age убогие?
_>>сравните средства разработки с VS.2003 и MSDN. _>>только в jBuilder я нащел что-то удовл. — там документация не просто javadocs. _>>я потерял ссылку, но это похожие: _>>http://www.jwz.org/doc/java.html _>>http://www.geocities.com/tablizer/javacrit.htm
G_>Провокационный вопрос: а на чем еще можно разрабатывать .NET кроме VS 2003?
скоро выйдет Improve C# под eclipse
G_>>>Про недостатки .NET сразу приходит в голову — отстутствие реальной кроссплатформенности _>>windows — это достаточно большой мир, чтобы волноватьмя о других платформах.
G_>Для домашних компьютеров — да, но для компаний все не так просто.
G_>>>и поддержки большого числа компаний. _>>я этого не знаю... я сколько времени на рынкке .NET и сколько Java ?
G_>Java — с 1995, .NET — с 2001.
Проектирование — это искусство, которым нельзя овладеть только с помощью теоретических занятий.
ВВ>>>Самое мощное средство разработки для .NET — это Visual Studio. Если не считать глюков, то по возможностям вполне прилично.
S>>Ребята, да поймите вы, люди привыкшие работать в Idea, работая в VS просто плачут.
_>У VS пасширяемая архитектура. Поставь поверх неё ReSharper и плакать не придётся. А впрочем в VS2005 уже есть многие полезные вещи, которые есть в ReSharperе.
а у Eclipse — не расширяемая?
видимо, SAP, сделавший свою DevStudio на Eclipse, — это сон ?
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, jdev333, Вы писали:
J>> а у Eclipse — не расширяемая? J>> видимо, SAP, сделавший свою DevStudio на Eclipse, — это сон ?
_>Приятно, наверное, что-то придумать, а потом с довольным видом опровергнуть...
ну и сказать о том, что в одной IDE есть что-то (что и в др. есть) хорошее, тоже, видимо, приятно
Здравствуйте, VladD2, Вы писали:
VD>Сейчас в Лонгхорне (новой версии Виндовс) ведется работа над тремя подсистемами: VD>1. Графической — Авалон.
Вот это хотел бы пощупать...
VD>2. Файловой — WinFS. Собственно это нманого больше чем файловая система. Это система хранения инфомации. Дастаточно сказать, что NTFS будет поддерживать транзакции и фичи обеспечение отказоустойчивости, а хранение данных приложений будет осуществляться в ОО-виде, и храниться они будут в MS SQL Server.
АААА.... Какой ужас!!! Представляю себе быстродействие файловой системы и сколько будет кушать памяти обертка работы с ней...
VD>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете?
Дотнета нет ни под одной другой осью кроме семейства Windows.
[RSDN@Home][1.2.0][alpha][619]
[Лучше изучить лишнее, чем ничего не изучить. [Сенека Старший]]
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Gregory_krovosos, Вы писали:
G_>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы. kuj>enumerations, fixed, using, unsafe, Interop...
Здравствуйте, n0name2, Вы писали:
I>>run-time generics
N>это как? чем от обычных отличаются?
Не знаю, что имеется ввиду под run-time generics, но то, что в Java не компилируется код
public class test2
{
public static void main(String[] args)
{
int i = 1;
LinkedList<int> list = new LinkedList<int>();
list.add(i);
int num = list.get(0);
}
}
по-моему, плохо. Что бы создать список из целых чисел, нужно в куче создать кучу объектов
I>>anonymous methods/iterators (yield return)...
N>анонимные классы есть, итераторы делаются с помощью простейшей библиотеки зачем их тащить в язык?
как ты спомощью библиотеки сделаешь следующее:
using System;
using System.Collections.Generic;
namespace test
{
public class Class1
{
List<int> list = new List<int>();
public IEnumerable<int> test()
{
foreach (int var in list) {
if (var % 2 == 0)
yield return var;
}
}
}
}
N>всякая ерунда для операций с COM на жабе ненужна вовсе...
_>public class test2
_>{
_> public static void main(String[] args)
_> {
_> int i = 1;
_> LinkedList<int> list = new LinkedList<int>();
_> list.add(i);
_> int num = list.get(0);
_> }
_>}
_>
по-моему, плохо. Что бы создать список из целых чисел, нужно в куче создать кучу объектов
есть десяток реализаций List который хранит int как примитив. но, они не быстрее стандартного ArrayList, я проверял. видимо — hotspot оптимизирует этот случай достаточно хорошо. в чем проблема использовать int []? вставка и поиск делаются простейшими утилитами.
_>как ты спомощью библиотеки сделаешь следующее:
легко RIFE Continuations. но именно в данном случае гораздо эффективнее бежать по массиву и к счетчику прибавлять двойку. и вообще — closures ИМХО гораздо более элегантны.
_>А зря. Legacy — великая вещь
как раз в Жабе все с этим в порядке — бинарная совместимость сверху вниз, самый старый API до сих пор отлично работает и т.д. а такая ерунда как COM нужна для Жабы раз в пять лет да и то лишь потому что заказчик хочет чего-то странного...
все вышеперечисленное (мелкие фенечки языка, которые смотрятся скорее как костыли к кривым концепциям) ерунда по сравнению с фундаментальными приемуществами Жабы. да и на уровне мелких фич полно гораздо более полезных вещей (по сравнению с итераторами и т.п.) которых нет в ДотНете.
Здравствуйте, n0name2, Вы писали:
N>все вышеперечисленное (мелкие фенечки языка, которые смотрятся скорее как костыли к кривым концепциям) ерунда по сравнению с фундаментальными приемуществами Жабы. да и на уровне мелких фич полно гораздо более полезных вещей (по сравнению с итераторами и т.п.) которых нет в ДотНете.
Да-да-да. Это крошечное бревно в моем глазу — полная ерунда по сравнению с фундаментальной соринкой в твоем.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
N>есть десяток реализаций List который хранит int как примитив. но, они не быстрее стандартного ArrayList, я проверял. видимо — hotspot оптимизирует этот случай достаточно хорошо. в чем проблема использовать int []? вставка и поиск делаются простейшими утилитами.
Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?
_>>как ты спомощью библиотеки сделаешь следующее:
N>легко RIFE Continuations. но именно в данном случае гораздо эффективнее бежать по массиву и к счетчику прибавлять двойку. и вообще — closures ИМХО гораздо более элегантны.
При чём тут веб? При чём тут прибавление к счётчику двойки? А closures давно в Java есть?
_>>А зря. Legacy — великая вещь
N>как раз в Жабе все с этим в порядке — бинарная совместимость сверху вниз, самый старый API до сих пор отлично работает и т.д. а такая ерунда как COM нужна для Жабы раз в пять лет да и то лишь потому что заказчик хочет чего-то странного...
N>все вышеперечисленное (мелкие фенечки языка, которые смотрятся скорее как костыли к кривым концепциям) ерунда по сравнению с фундаментальными приемуществами Жабы.
Что конкретно имеется в виду под "Фундаментальными Приемуществами"? А "мелкие фенички языка" это наверное поддержка генериков на уровне рантайма, а не обёртка в них старого когда?
да и на уровне мелких фич полно гораздо более полезных вещей (по сравнению с итераторами и т.п.) которых нет в ДотНете.
Здравствуйте, anton_t, Вы писали:
_>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?
а часто в середину надо? раз в полгода? какова сложность итерации списка/массива?
_>При чём тут веб? При чём тут прибавление к счётчику двойки? А closures давно в Java есть?
при том, что для более простых случаев yield вообще не нужен, все гораздо проще и эффективнее делается. и вообще — когда в последний раз вам надо было свой итератор писать? closures на уровне анонимных классов обычно делают.
_>Что конкретно имеется в виду под "Фундаментальными Приемуществами"? А "мелкие фенички языка" это наверное поддержка генериков на уровне рантайма, а не обёртка в них старого когда?
1. открытый код (соот-но можно делать свои реализации JVM с минимальными усилиями и их потом продавать). например, можно легко сделать версию JDK с поддержкой тогоже yield и распространять ее за 5 баксов.
2. открытые стандарты. думаю пояснять ненадо.
3. платформонезависимость (моно это совершенно несерьезно). рынок линуха, соляриса особенно серверный — весьма и весьма большой. да и парк железа не интеловского (sun fire, ibm power, cell вот скоро будет) огромен, особенно в больших западных конторах.
4. огромное кол-во разнообразного софта, библиотек, аппликэйшн серверов и т.д. скажем, есть несколько альтернативных JVM, компилятор в нативный код, десятки серверов приложений, расширения языка и т.д... майкрософт при всех его возможностях физически не может произвести на свет объем софта сравнимый с тем что порождает open source community (причем качество во втором случае часто выше).
5. Java полностью бесплатна и работает на бесплатном софте. в некоторых случаях это очень существенно (сколько будут стоить лицензии на 1000 блейд серверов?), несмотря на то что майкрософт пытается доказать что стоимость владения линухом якобы выше (что полный бред).
_>да и на уровне мелких фич полно гораздо более полезных вещей (по сравнению с итераторами и т.п.) которых нет в ДотНете.
_>Каких?
ну, например (наиболее очевидное)
1. NIO (селекторы, буферы) — это совсем не асинхронные потоки. позволяет использовать хитрые фичи современных storage систем достаточно эффективно.
2. java.util.concurrent — чрезвычайно полезная библиотека для создания многопоточных приложений
3. garbage collector — автоматическая настройка параметров под заданные цели (занимать 1/N времени процессора, пауза не более M миллисекунд), очень много разных ручных настроек позволяющих полностью контролировать процесс.
4. независимость веб приложений от IIS, скажем, почти все жабные веб сервера живут в одном процессе с собственно HTTP сервером. в результате во многих случаях тотже Resin (продается за 500 баксов) делает IIS + .NET в разы.
5. IntelliJ IDEA (решэйпер это пока что жалкое подобие, как и студия 2005)
6. 64bit — я так понимаю что windows server 64bit до сих пор в глубокой бете, а большой хип а Жабе я использую уже больше года.
можно пройтись еще по web app frameworks, middleware и т.д. и т.п.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
_>>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?
N>а часто в середину надо? раз в полгода? какова сложность итерации списка/массива?
А если всё-таки надо и часто?
_>>При чём тут веб? При чём тут прибавление к счётчику двойки? А closures давно в Java есть?
N>при том, что для более простых случаев yield вообще не нужен, все гораздо проще и эффективнее делается. и вообще — когда в последний раз вам надо было свой итератор писать? closures на уровне анонимных классов обычно делают.
yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что?
_>>Что конкретно имеется в виду под "Фундаментальными Приемуществами"? А "мелкие фенички языка" это наверное поддержка генериков на уровне рантайма, а не обёртка в них старого когда?
N>1. открытый код (соот-но можно делать свои реализации JVM с минимальными усилиями и их потом продавать). например, можно легко сделать версию JDK с поддержкой тогоже yield и распространять ее за 5 баксов.
Во-первых эта JDK не будет соответствовать стандарту, а во вторых продавать не сможешь — другие возьмут твою JVM и будут продавать за 3 бакса.
N>2. открытые стандарты. думаю пояснять ненадо.
И чем же они открытее стандартов на .NET и C#?
N>3. платформонезависимость (моно это совершенно несерьезно). рынок линуха, соляриса особенно серверный — весьма и весьма большой. да и парк железа не интеловского (sun fire, ibm power, cell вот скоро будет) огромен, особенно в больших западных конторах.
Ну рынок вообще-то существует МЕЖДУ конторами, а не В НИХ.
N>4. огромное кол-во разнообразного софта, библиотек, аппликэйшн серверов и т.д. скажем, есть несколько альтернативных JVM, компилятор в нативный код, десятки серверов приложений, расширения языка и т.д... майкрософт при всех его возможностях физически не может произвести на свет объем софта сравнимый с тем что порождает open source community (причем качество во втором случае часто выше).
А что, под .NET может писать только Microsoft? Что же тогда делаю я?
N>5. Java полностью бесплатна и работает на бесплатном софте. в некоторых случаях это очень существенно (сколько будут стоить лицензии на 1000 блейд серверов?), несмотря на то что майкрософт пытается доказать что стоимость владения линухом якобы выше (что полный бред).
Не знаю как соотносятся стоимости влядения винды и линуха, но утверждение Microsoft не более голословно, чем твоё.
_>>да и на уровне мелких фич полно гораздо более полезных вещей (по сравнению с итераторами и т.п.) которых нет в ДотНете.
_>>Каких?
N>ну, например (наиболее очевидное)
N>1. NIO (селекторы, буферы) — это совсем не асинхронные потоки. позволяет использовать хитрые фичи современных storage систем достаточно эффективно.
В .NET своих "хитрых фич" хватает.
N>2. java.util.concurrent — чрезвычайно полезная библиотека для создания многопоточных приложений
И что в ней семафоры-мьютексы разные? Так они и в .NET есть.
N>3. garbage collector — автоматическая настройка параметров под заданные цели (занимать 1/N времени процессора, пауза не более M миллисекунд), очень много разных ручных настроек позволяющих полностью контролировать процесс.
Подозреваю, что такими "улучшениями" можно такого наворотить...
N>4. независимость веб приложений от IIS, скажем, почти все жабные веб сервера живут в одном процессе с собственно HTTP сервером. в результате во многих случаях тотже Resin (продается за 500 баксов) делает IIS + .NET в разы.
А разве веб-сервер и http-сервер не синонимы?
N>5. IntelliJ IDEA (решэйпер это пока что жалкое подобие, как и студия 2005)
Ждём Resharper 2.0.
N>6. 64bit — я так понимаю что windows server 64bit до сих пор в глубокой бете, а большой хип а Жабе я использую уже больше года.
А какая разница под чем Java крутится. Она же платформенно-независимая?
N>можно пройтись еще по web app frameworks, middleware и т.д. и т.п.
Здравствуйте, jdev333, Вы писали:
J>имхо, микрософт может не управиться в конкурентное время с платформой J>как я понимаю до сих пор нету аналога серверов приложений, а они уже сейчас сами по себе отходят на второй план — посмотрите что делают SAP, Oracle, IBM, BEA и др. (уже) — портал + warehouse + integration broker + app_server- переход к сервисной архитектуре (не путать с веб-сервисами)
Здравствуйте, anton_t, Вы писали:
_>А если всё-таки надо и часто?
тогда возьми одну из 100 реализаций List с примитивным int в качестве элемента. тамже есть с double, и всеми прочими. только она работать будет скорее всего чуть медленнее чем LinkedList<Integer>.
_>yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что?
пример конкретной задачи, если не сложно. про count%2 уже понял — делается элементарно.
_>Во-первых эта JDK не будет соответствовать стандарту, а во вторых продавать не сможешь — другие возьмут твою JVM и будут продавать за 3 бакса.
зависит от того какой license agreement будет у твоей JVM.
N>>2. открытые стандарты. думаю пояснять ненадо.
_>И чем же они открытее стандартов на .NET и C#?
тем что они не контролируются Sun а являются результатом согласия community. кроме того, не уверен что на технологии .NET есть открытый и четкий стандарт с версиями, обратной совместимостью, тестами и т.д.
_>Ну рынок вообще-то существует МЕЖДУ конторами, а не В НИХ.
тем не менее спрос на nonmicrosoft/nonintel весьма широкий.
_>А что, под .NET может писать только Microsoft? Что же тогда делаю я?
без исходного кода платформы возможности девелоперов весьма ограничены. кроме того — политика мс подавляет конкурирующие сторонние решения.
_>В .NET своих "хитрых фич" хватает.
ну и? ты просил я перечислил... NIO не просто хитрая фича а то что позволяет держать тысячи TCP соединений особенно не напрягаясь.
N>>2. java.util.concurrent — чрезвычайно полезная библиотека для создания многопоточных приложений
_>И что в ней семафоры-мьютексы разные? Так они и в .NET есть.
нее... там намного более хитрые вещи чем тривиальные мьютексы.
N>>3. garbage collector — автоматическая настройка параметров под заданные цели (занимать 1/N времени процессора, пауза не более M миллисекунд), очень много разных ручных настроек позволяющих полностью контролировать процесс.
_>Подозреваю, что такими "улучшениями" можно такого наворотить...
без них я вообще не представляю себе работы. т.к. одно приложение ориентировано на throughput, второе на низкие задержки и т.д.
N>>4. независимость веб приложений от IIS, скажем, почти все жабные веб сервера живут в одном процессе с собственно HTTP сервером. в результате во многих случаях тотже Resin (продается за 500 баксов) делает IIS + .NET в разы.
_>А разве веб-сервер и http-сервер не синонимы?
я имел в виду собственно бизнес логику и логику формирования страниц. короче — IIS + .NET это два процесса и коммуникации м/у процессами а Resin/Tomcat/whatever это один процесс.
N>>5. IntelliJ IDEA (решэйпер это пока что жалкое подобие, как и студия 2005)
_>Ждём Resharper 2.0.
к тому времени уже demetra выйдет... так со многими продуктами — NHibernate, или там NLucene — порты старых версий, основные усилия на Java версии сосредоточены.
N>>6. 64bit — я так понимаю что windows server 64bit до сих пор в глубокой бете, а большой хип а Жабе я использую уже больше года.
_>А какая разница под чем Java крутится. Она же платформенно-независимая?
памяти если надо больше 4гб, то без 64х бит тяжело.
N>>можно пройтись еще по web app frameworks, middleware и т.д. и т.п.
_>Давай пройдёмся.
N>я имел в виду собственно бизнес логику и логику формирования страниц. короче — IIS + .NET это два процесса и коммуникации м/у процессами а Resin/Tomcat/whatever это один процесс.
Здесь ты не прав. Начиная с IIS6 (Windows Server 2003) asp.net интегрируется непосредственно в iis и исполняется в том же процессе.
N>>>6. 64bit — я так понимаю что windows server 64bit до сих пор в глубокой бете, а большой хип а Жабе я использую уже больше года.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
_>>А если всё-таки надо и часто?
N>тогда возьми одну из 100 реализаций List с примитивным int в качестве элемента. тамже есть с double, и всеми прочими. только она работать будет скорее всего чуть медленнее чем LinkedList<Integer>.
И ради этого мне придётся тянуть стороннюю библиотеку. Да ещё и медленнее работать будет.
_>>yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что?
N>пример конкретной задачи, если не сложно. про count%2 уже понял — делается элементарно.
Каой задачи?
Про count%2 — даже элементарнее чем в моём примере?
_>>Во-первых эта JDK не будет соответствовать стандарту, а во вторых продавать не сможешь — другие возьмут твою JVM и будут продавать за 3 бакса.
N>зависит от того какой license agreement будет у твоей JVM.
Добро пожаловать в соседнюю ветку про GPL
N>>>2. открытые стандарты. думаю пояснять ненадо.
_>>И чем же они открытее стандартов на .NET и C#?
N>тем что они не контролируются Sun а являются результатом согласия community. кроме того, не уверен что на технологии .NET есть открытый и четкий стандарт с версиями, обратной совместимостью, тестами и т.д.
И всё-таки я не понял, чем стандарты на Java открытее чем эти:
Ну и что? "За двумя зайцами погонишься — ни одного не поймаешь."
_>>А что, под .NET может писать только Microsoft? Что же тогда делаю я?
N>без исходного кода платформы возможности девелоперов весьма ограничены.
Reflector тебе в руки.
N>кроме того — политика мс подавляет конкурирующие сторонние решения.
Хочется тебя огорчить — любая коммерческая организация стремится обойти конкурентов.
N>>>2. java.util.concurrent — чрезвычайно полезная библиотека для создания многопоточных приложений
_>>И что в ней семафоры-мьютексы разные? Так они и в .NET есть.
N>нее... там намного более хитрые вещи чем тривиальные мьютексы.
Здравствуйте, n0name2, Вы писали:
_>>yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что? N>пример конкретной задачи, если не сложно. про count%2 уже понял — делается элементарно.
Вот класс элемента дерева с поддержкой обхода всех детей:
public class TreeNode
{
public IEnumerable<TreeNode> Children
{
get
{
return _children;
}
}
private List<TreeNode> _children = new List<TreeNode>;
// внимание, пошел трюк:public IEnumerable<TreeNode> AllChildren
{
get
{
foreach(TreeNode child in Children)
{
yield return child;
foreach(TreeNode descendant in child.AllChildren)
yield return descendant;
}
}
}
}
Покажи мне, как это здорово делается на Java.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здесь ты не прав. Начиная с IIS6 (Windows Server 2003) asp.net интегрируется непосредственно в iis и исполняется в том же процессе.
хмм... тут недавно один маркетолог из MS заходил на tss.net и тужился протолкнуть бенчмарк в котором утверждалость что .NET 2.0 в два раза быстрее IBM WebSphere. его быстро обломали ответным бенчмарком в котором Resin раза в два — три обходит .NET 2.0 (причем, даже MSовские инженеры это воспроизвели), он сильно удивился и начал напирать на то что мол процессы разные и т.д. вроде там все было только под NET 2.0 on Windows Server 2003. если я неправ, то значит просто IIS + ASP.NET тормоз, а альтернативы ему на .NET не существует.
N>>>>6. 64bit — я так понимаю что windows server 64bit до сих пор в глубокой бете, а большой хип а Жабе я использую уже больше года.
AA>Сведения с сайта MSDN Subscriptions.
а это не бета случайно? и сколько это счастье стоит на два физических процессора?
и это все? а спецификации того как работает IIS, ASP, WinForms, MTS и т.д. и т.п.? где официальные тесты, позволяющие сертифицировать альтернативную реализацию на соответствие стандарту? кто владеет правами на эти стандарты и гарантирует совместимость снизу вверх? кто учавствует в их разработке?
N>>тем не менее спрос на nonmicrosoft/nonintel весьма широкий. _>Ну и что? "За двумя зайцами погонишься — ни одного не поймаешь."
Жаба легко и непринужденно работает везде. куча софта работает под всеми популярными платформами и очень многие значительно лучше чем софт от MS (скажем, Oracle, SAP и т.п.). собственно, поддержка многих платформ по большому счету не требует невероятного кол-ва ресурсов, в отличае от попытки проникнуть на все рынки подряд грубо воруя чужие идеи, выпуская сырые и кривые продукты, опираясь только на маркетинг. думаю, если бы MS тихо и спокойно развивал desktop OS и офисный пакет его финансовые показатели были бы намного лучше а продукты выходили бы вовремя и без урезания бОльшей части планируемых фич. кстати, думаю что после ухода Билли на пенсию контору распилят на части и все станет на свои места.
N>>кроме того — политика мс подавляет конкурирующие сторонние решения. _>Хочется тебя огорчить — любая коммерческая организация стремится обойти конкурентов.
обойти — да. но монополизироваты рынок — далеко не всякая. Sun например, создала рынок J2EE серверов приложений, но сама на нем присутствует только с референсной (бесплатной) реализацией. и это только на пользу платформы в целом — разные реализации имеют разные плюсы, можно выбирать ту, которая больше подходит под конкретный продукт. ну, и конкуренция м/у вендорами приводит к тому что продукты в целом более качественны. рынка аналогов IIS/ASP небудет никогда т.к. MS его подавляет искуственно.
N>>нее... там намного более хитрые вещи чем тривиальные мьютексы. _>Какие?
нетривиальное из того, что я использую: ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArraySet, CyclicBarrier, CountDownLatch, Exchanger, Executor, ScheduledThreadPoolExecutor, AtomicReferenceFieldUpdater, AtomicMarkableReference
большинство из этого можно сделать так или иначе на .NET, но нужно очень и очень глубоко вникать в memory model, большой объем работы по peer review и тестированию.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
N>Жаба легко и непринужденно работает везде. куча софта работает под всеми популярными платформами и очень многие значительно лучше чем софт от MS (скажем, Oracle, SAP и т.п.).
По крайней мере на винде .NET удобнее.
N>собственно, поддержка многих платформ по большому счету не требует невероятного кол-ва ресурсов, в отличае от попытки проникнуть на все рынки подряд грубо воруя чужие идеи, выпуская сырые и кривые продукты, опираясь только на маркетинг.
А как там XMLDOM в Java, уже без глюков работает?
N>думаю, если бы MS тихо и спокойно развивал desktop OS и офисный пакет его финансовые показатели были бы намного лучше а продукты выходили бы вовремя и без урезания бОльшей части планируемых фич. кстати, думаю что после ухода Билли на пенсию контору распилят на части и все станет на свои места.
Ну прям гений маркетинга
N>>>кроме того — политика мс подавляет конкурирующие сторонние решения. _>>Хочется тебя огорчить — любая коммерческая организация стремится обойти конкурентов.
N>обойти — да. но монополизироваты рынок — далеко не всякая. Sun например, создала рынок J2EE серверов приложений, но сама на нем присутствует только с референсной (бесплатной) реализацией. и это только на пользу платформы в целом — разные реализации имеют разные плюсы, можно выбирать ту, которая больше подходит под конкретный продукт. ну, и конкуренция м/у вендорами приводит к тому что продукты в целом более качественны. рынка аналогов IIS/ASP небудет никогда т.к. MS его подавляет искуственно.
Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
N>>>нее... там намного более хитрые вещи чем тривиальные мьютексы. _>>Какие?
N>нетривиальное из того, что я использую: ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArraySet, CyclicBarrier, CountDownLatch, Exchanger, Executor, ScheduledThreadPoolExecutor, AtomicReferenceFieldUpdater, AtomicMarkableReference
N>большинство из этого можно сделать так или иначе на .NET, но нужно очень и очень глубоко вникать в memory model, большой объем работы по peer review и тестированию.
S>public class TreeNode
S>{
S> public IEnumerable<TreeNode> Children
S> {
S> get
S> {
S> return _children;
S> }
S> }
S> private List<TreeNode> _children = new List<TreeNode>;
S> // внимание, пошел трюк:
S> public IEnumerable<TreeNode> AllChildren
S> {
S> get
S> {
S> foreach(TreeNode child in Children)
S> {
S> yield return child;
S> foreach(TreeNode descendant in child.AllChildren)
S> yield return descendant;
S> }
S> }
S> }
S>}
S>
S>Покажи мне, как это здорово делается на Java.
ну, собственно никто не спорит — штука неплохая, но, реального value от нее не так уж и много. можно, например, так:
public class TestTree {
public static interface Closure<T> {
public void execute(T object);
}
public static class TreeNode {
private List<TreeNode> children = new ArrayList<TreeNode>();
public void traverse(Closure<TreeNode> closure) {
closure.execute(this);
for (TreeNode child : children) child.traverse(closure);
}
}
public static void main(String [] args) {
new TreeNode().traverse(new Closure<TreeNode>() {
public void execute(TreeNode object) {
System.out.println(object);
}
});
}
}
Здравствуйте, anton_t, Вы писали:
_>По крайней мере на винде .NET удобнее.
ну с такой постановкой вопроса практически согласен, с одной поправкой — только для десктопных приложений (которые конечно хороши, но все большая популярность тонких клиентов наводит на размышления).
_>А как там XMLDOM в Java, уже без глюков работает?
вообще, есть десяток реализаций DOM/SAX для Java, есть и более продвинутые/быстрые API (StAX, etc). а для .NET кто-то это делает? или MS демотивирует — мол есть наша им и пользуйся?
_>Ну прям гений маркетинга
а ты сам посмотри — от всего кроме винды и офиса по большей части одни убытки у них... влучшем случае в ноль выходят.
_>Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
это прекрасно что .NET появился (для конкуренции), но на основе того что там есть yield (delegate, etc что достаточно просто делается без расширения языка) утверждать что он лучше... причем отметая намного более серьезные аргументы (да одни тонкие настройки ЖЦ гораздо более полезны чем все доп конструкции C# вместе взятые т.к. это никакими конструкциям в коде не заменить)...
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
_>>По крайней мере на винде .NET удобнее.
N>ну с такой постановкой вопроса практически согласен, с одной поправкой — только для десктопных приложений (которые конечно хороши, но все большая популярность тонких клиентов наводит на размышления).
Спорная поправка.
_>>А как там XMLDOM в Java, уже без глюков работает?
N>вообще, есть десяток реализаций DOM/SAX для Java, есть и более продвинутые/быстрые API (StAX, etc). а для .NET кто-то это делает? или MS демотивирует — мол есть наша им и пользуйся?
А зачем изобретать велосипед, если то что есть отлично работает? Как Microsoft может мне запретить сделать свою реализацию DOMXML?
_>>Ну прям гений маркетинга
N>а ты сам посмотри — от всего кроме винды и офиса по большей части одни убытки у них... влучшем случае в ноль выходят.
Люди, наверное, о будущем думают.
_>>Если бы Microsoft не продвигала активно .NET, то Java бы его задавила по праву первого.
N>это прекрасно что .NET появился (для конкуренции), но на основе того что там есть yield (delegate, etc что достаточно просто делается без расширения языка) утверждать что он лучше... причем отметая намного более серьезные аргументы (да одни тонкие настройки ЖЦ гораздо более полезны чем все доп конструкции C# вместе взятые т.к. это никакими конструкциям в коде не заменить)...
Тут уже приводили преимущества .NET, поищи в этом топике.
Здравствуйте, anton_t, Вы писали:
_>А зачем изобретать велосипед, если то что есть отлично работает? Как Microsoft может мне запретить сделать свою реализацию DOMXML?
например, для того чтобы быстрее работало. или для того чтобы поддержать более новую версию стандарта пока Sun не проапдейтит JDK. всякие новомодные легкие потоковые парсеры XML работают в разы быстрее DOM. MS не запретит, но исходя из идеалогии исходящей от MS этим парсером просто не будут пользоватся а будут ждать .NET 3.0 если есть проблемы во второй версии. кстати, исходники .NET DOM открыты или нет? на их основе можно что-нить делать?
_>Люди, наверное, о будущем думают.
в итоге превращают контору в монстра занимающимся всем и вся. как следствие недостаточное внимание к core products. о будующем подумают и другие, Гугл, например, у него, ИМХО, лучше получается.
_>Тут уже приводили преимущества .NET, поищи в этом топике.
так они все либо направлены на поддержку COM либо аналогичны по сути yield. ничего фундаментального (т.е. того что невозможно исправить простейшим расширением языка/рантайма) я не увидел. кстати, одно время generics были только в виде спецификации, но людям хотелось побыстрее их получить и имел довольно широкое распространение плагин к компилятору их реализующий (в силу закрытости компилятора для .NET, скорее всего, такое сделать нельзя, как насчет плагина с checked exceptions?).
если кому-нибудь всерьез был бы нужен yield/delegate/fixed/etc давно бы уже сделали аналогичный плагин, но это просто в голову никому не приходит т.к. можно сделать все тоже самое с помощью простых аналогов...
Здравствуйте, n0name2, Вы писали:
N>ну, собственно никто не спорит — штука неплохая, но, реального value от нее не так уж и много. можно, например, так:
N>
N>public class TestTree {
N> public static interface Closure<T> {
N> public void execute(T object);
N> }
N> public static class TreeNode {
N> private List<TreeNode> children = new ArrayList<TreeNode>();
N> public void traverse(Closure<TreeNode> closure) {
N> closure.execute(this);
N> for (TreeNode child : children) child.traverse(closure);
N> }
N> }
N> public static void main(String [] args) {
N> new TreeNode().traverse(new Closure<TreeNode>() {
N> public void execute(TreeNode object) {
N> System.out.println(object);
N> }
N> });
N> }
N>}
N>
Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
я согласен с тобой — итератор будет сделать относительно сложно. хотя, в java.util.TreeMap такой имеется и занимает, ну, пусть 30 строк (приводить не буду, с твоего позволения, ничего примечательного там нет).
но я не согласен что так нельзя. чем замыкание хуже итератора? по сути задача решена, причем весьма просто.
если где-то есть какой-то legacy код (неприкосновенный) и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Sinclair, Вы писали:
S>>Неа. Так — нельзя. У нас уже есть готовый метод, который принимает на вход IEnumerable<T>. Ты схитрил, и вместо итератора реализовал вызов замыкания. У нас базовым примитивом является не фрагмент кода, а итератор. Так что, пожалуйста, перепиши код так, чтобы реализовать именно итератор.
N>я согласен с тобой — итератор будет сделать относительно сложно. хотя, в java.util.TreeMap такой имеется и занимает, ну, пусть 30 строк (приводить не буду, с твоего позволения, ничего примечательного там нет).
N>но я не согласен что так нельзя. чем замыкание хуже итератора? по сути задача решена, причем весьма просто.
Нет! Задача никак не решена. Дело в том, что в отличие от замыкания, итератор можно трансформировать. Вот, например, я пишу фильтр на итераторах:
public static IEnumerable<T> FindAll<T>(IEnumerable<T> input, Predicate<T> predicate)
{
foreach(T item in input)
if (predicate(item))
yield return item;
}
Как ты его напишешь на замыканиях? N>если где-то есть какой-то legacy код (неприкосновенный)
Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть? У меня в CollectionHelper и такой метод есть:
/// <summary>
/// Sorts the input using the specified key
/// </summary>
/// <typeparam name="T">The type of the enumerable - normally may be omitted since
/// compiler derives it from the first argument</typeparam>
/// <typeparam name="TKey">The type of the key to perform comparison by. Must implement IComparable<TKey></typeparam>
/// <param name="collection">Source collection</param>
/// <param name="by">The key expression</param>
/// <returns>Array sorted by </returns>public static T[] Sort<T, TKey>(IEnumerable<T> collection, Converter<T, TKey> by)
where TKey: IComparable<TKey>
{
return Sort(collection, delegate(T x, T y) { return by(x).CompareTo(by(y)); });
}
Вот как это может использоваться:
IEnumerable<TreeNode> filtered = CollectionHelper.FindAll(Tree.Nodes.Root.AllChildren, delegate(TreeNode tn) { return tn.Weight>10; });
foreach(TreeNode node in CollectionHelper.Sort(filtered, delegate(TreeNode tn) { return tn.Name; }))
{
Console.Write(node);
}
N> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру.
И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть?
public class TestTree {
public static interface Closure<T> {
public void execute(T object);
}
public static interface Predicate<T> {
public boolean evaluate(T object);
}
public static class TreeNode {
private List<TreeNode> children = new ArrayList<TreeNode>();
public void traverse(Closure<TreeNode> closure, Predicate<TreeNode> predicate) {
if (predicate.evaluate(this)) closure.execute(this);
for (TreeNode child : children) child.traverse(closure, predicate);
}
public void iterate(Closure<TreeNode> closure, Predicate<TreeNode> predicate, Comparator<TreeNode> comparator) {
final List<TreeNode> temp = new ArrayList<TreeNode>();
traverse(new Closure<TreeNode>() { public void execute(TreeNode object) { temp.add(object); } }, predicate);
Collections.sort(temp, comparator); for (TreeNode node : temp) closure.execute(node);
}
}
public static void main(String [] args) {
new TreeNode().iterate(
new Closure<TreeNode>() {
public void execute(TreeNode object) { System.out.println(object); }
},
new Predicate<TreeNode>() {
public boolean evaluate(TreeNode object) { return object != null; }
},
new Comparator<TreeNode>() {
public int compare(TreeNode x, TreeNode y) { return 0; }
});
}
}
например так... кстати, можно во время копирования и сортировку делать заодно (бинарным поиском). а вообще, я бы сделал LinkedTree, параллельно хранил бы элементы дерева в списке. заодно в виде бонуса получил бы упорядоченность по времени вставки (или по другому параметру) и быструю итерацию по массиву...
N>> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру. S>И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
а что за деревья такие, если не секрет? каково там кол-во элементов? вот у меня поиск по слову tree не выдает ни одного совпадения. если они где и есть, то используются через SAX или connect by prior в Оракле...
Здравствуйте, n0name2, Вы писали:
S>>Дело не в легаси. Дело в том, что итераторы я могу легко комбинировать. С замыканиями это намного сложнее. Если фильтр еще можно попытаться воспроизвести (хотя эффект будет не таким — фильтр придется применять не к исходной коллекции, а к замыканию), то с сортировкой как быть?
N>например так... кстати, можно во время копирования и сортировку делать заодно (бинарным поиском). а вообще, я бы сделал LinkedTree, параллельно хранил бы элементы дерева в списке. заодно в виде бонуса получил бы упорядоченность по времени вставки (или по другому параметру) и быструю итерацию по массиву...
Вот это и плохо. То есть ты все то, что я бесплатно имею, единожды написав класс CollectionHelper для всех вообще коллекций, вынужден делать для каждого TreeNode.
N>>> и есть задача вроде обхода дерева когда итератор без yield написать сложно, то для него можно один раз в жизни написать итератор (переиспользуемый). чаще чем раз в 20 лет не думаю что такая комбинация условий выпадет простому программеру. S>>И вот очень зря ты так думаешь. Потому, что вот такое дерево мы изобретаем ежедневно. Вот я запустил поиск по проекту — yield return используется в 26 файлах, лень считать сколько именно раз.
N>а что за деревья такие, если не секрет? каково там кол-во элементов? вот у меня поиск по слову tree не выдает ни одного совпадения. если они где и есть, то используются через SAX или connect by prior в Оракле...
Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вот это и плохо. То есть ты все то, что я бесплатно имею, единожды написав класс CollectionHelper для всех вообще коллекций, вынужден делать для каждого TreeNode.
во-первых это я просто в примере написал iterate() как метод внутри TreeNode, собственно это можно вынести в Helper легко. во-вторых, зачем делать много TreeNode если можно сделать один универсальный?
S>Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
и только немногие из них, ИМХО, относительно сложно написать без yield, кстати, STL отлично без этого справляется.
короче. yield штука полезная, изредка. но рассматривать это как некое приемущество дотнета я бы не стал, ну, так, интересная особенность языка... честно говоря, на месте Sun я не стал бы это включать в язык только потому что ввод нового ключевого слова может отразится на совместимости.
кроме того, есть библиотека классов Generic Algorithms for Java, в т.ч. готовые итераторы (с фильтрацией, объеденение двух и более, возвращающие только уникальные значения и т.д. и т.п.) на ВСЕ случаи жизни. честно говоря, ни разу не сталкивался с потребностью написать что-то не укладывающееся в ее концепции.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, n0name2, Вы писали:
_>>>yield делает сложное более простым. С чего вы взяли, что ты сможешь сделать проще и эффективнее без yield, чем с yield? Последний раз на прошлой неделе писал, а что? N>>пример конкретной задачи, если не сложно. про count%2 уже понял — делается элементарно. S>Вот класс элемента дерева с поддержкой обхода всех детей: S>
S>public class TreeNode
S>{
S> public IEnumerable<TreeNode> Children
S> {
S> get
S> {
S> return _children;
S> }
S> }
S> private List<TreeNode> _children = new List<TreeNode>;
S> // внимание, пошел трюк:
S> public IEnumerable<TreeNode> AllChildren
S> {
S> get
S> {
S> foreach(TreeNode child in Children)
S> {
S> yield return child;
S> foreach(TreeNode descendant in child.AllChildren)
S> yield return descendant;
S> }
S> }
S> }
S>}
S>
S>Покажи мне, как это здорово делается на Java.
Предупреждаю сразу не компилировал, но работать должно. Жду гнилых помидоров
public class TreeNode implements Iterable<TreeNode> {
private List<TreeNode> childrens = new ArrayList<TreeNode>();
public Iterator<TreeNode> iterator() {
return childrens.iterator();
}
public Iterator<TreeNode> getAllChildrens() {
MultiIterator<TreeNode> it = new MultiIterator<TreeNode>();
for(TreeNode child : this) {
it.addIterator(child.getAllChildrens());
}
}
public static class MultiIterator implements Iterator<TreeNode> {
private List<Iterator<TreeNode>> iterators = new ArrayList<Iterator<TreeNode>>();
int i = 0;
public void addIterator(Iterator<TreeNode> it) {
iterators.add(it);
}
public TreeNode next() {
if(hasNext()) {
return iterators.get(i).next();
}
throw NoSuchElementFound();
}
public boolean hasNext() {
while(i < iterators.size())
if(iterators.get(i).hasNext()) {
return true;
}
i++;
}
retun false;
}
}
}
Здравствуйте, Loafer, Вы писали: S>>Покажи мне, как это здорово делается на Java. L>Предупреждаю сразу не компилировал, но работать должно. Жду гнилых помидоров
public class TreeNode implements Iterable<TreeNode> {
private List<TreeNode> childrens = new ArrayList<TreeNode>();
public Iterator<TreeNode> iterator() {
return childrens.iterator();
}
public Iterator<TreeNode> getAllChildrens() {
MultiIterator<TreeNode> it = new MultiIterator<TreeNode>();
for(TreeNode child : this) {
it.addIterator(child.getAllChildrens());
}
return it; // надо полагать?
}
Прекрасная идея. В отличие от тупикового пути с замыканиями.
Есть только одно "но": в отличие от дотнетной, эта реализация не "ленивая". Т.е. первое же обращение к Tree.getRoot().getAllChildren() приведет к почти полному обходу дерева — кроме листьев. Прелесть yield в том, что он исполняется по мере необходимости. К примеру, если я делаю CollectionHelper.Find(Tree.Root.AllChildren, ...), то обход прекратится сразу же, как только я найду нужный элемент.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали:
N>во-первых это я просто в примере написал iterate() как метод внутри TreeNode, собственно это можно вынести в Helper легко.
Гм. Ты не мог бы показать, как именно это сделать? Причем желательно, чтобы iterate() не зависел от TreeNode. N> во-вторых, зачем делать много TreeNode если можно сделать один универсальный?
S>>Site Map, структура файловой системы. Это только пример — коллекции не ограничиваются деревьями. Итератор — это очень мощная абстракция. См. напр. STL.
N>и только немногие из них, ИМХО, относительно сложно написать без yield, кстати, STL отлично без этого справляется.
Гм. Ничего сложного, конечно, нет. Просто для того, чтобы написать каждый способ получения итератора, нужно как минимум два класса. Один — реализующий собственно итератор, и второй, отдающий этот класс. Вместо трех строчек получаем тридцать.
N>короче. yield штука полезная, изредка. но рассматривать это как некое приемущество дотнета я бы не стал, ну, так, интересная особенность языка... честно говоря, на месте Sun я не стал бы это включать в язык только потому что ввод нового ключевого слова может отразится на совместимости.
N>кроме того, есть библиотека классов Generic Algorithms for Java, в т.ч. готовые итераторы (с фильтрацией, объеденение двух и более, возвращающие только уникальные значения и т.д. и т.п.) на ВСЕ случаи жизни. честно говоря, ни разу не сталкивался с потребностью написать что-то не укладывающееся в ее концепции.
Ок. Нельзя ли продемонстрировать применение такого механизма для выдачи, допустим, хотя бы тех же листьев дерева, отобранных по условию?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
VD>>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете? S>Дотнета нет ни под одной другой осью кроме семейства Windows.
Вот вам, дорогой вы наш, .Net под:
Mac OS X
SUSE Linux (x86/x86-64/IA64/S390)
RedHat Linux (x86/x86-64/IA64/S390)
Здравствуйте, Azix, Вы писали:
A>Здравствуйте, Sheridan, Вы писали:
VD>>>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете? S>>Дотнета нет ни под одной другой осью кроме семейства Windows.
A>Вот вам, дорогой вы наш, .Net под: A>Mac OS X A>SUSE Linux (x86/x86-64/IA64/S390) A>RedHat Linux (x86/x86-64/IA64/S390)
A>http://www.mono-project.com/Downloads
A>Под Solaris нету, извините, там Java.
Здравствуйте, Azix, Вы писали:
A>Вот вам, дорогой вы наш, .Net под: A>Mac OS X A>SUSE Linux (x86/x86-64/IA64/S390) A>RedHat Linux (x86/x86-64/IA64/S390)
A>http://www.mono-project.com/Downloads
Гоаорят — малое подобие левой руки.
[RSDN@Home][1.2.0][alpha][621]
[Кто не знает, что такое мир, не знает, где он сам... [Марк Аврелий]]
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Azix, Вы писали:
A>>Вот вам, дорогой вы наш, .Net под: A>>Mac OS X A>>SUSE Linux (x86/x86-64/IA64/S390) A>>RedHat Linux (x86/x86-64/IA64/S390)
A>>http://www.mono-project.com/Downloads
S>Гоаорят — малое подобие левой руки.
Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell.
Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net.
Не думаю, что Java может предложить что-то похожее.
Здравствуйте, Sinclair, Вы писали:
S>Гм. Ты не мог бы показать, как именно это сделать? Причем желательно, чтобы iterate() не зависел от TreeNode.
кстати, код ниже, ИМХО, лучше чем версия с мульти итератором хотябы тем, что не пораждает столькоже итераторов сколько ветвей у дерева. ну и позволяет частичную итерацию (достаточно бросить исключение в Closure или завести возвращаемое значение + флажок).
public class TestTree {
public static interface Closure<T> {
public void execute(T object);
}
public static interface Predicate<T> {
public boolean evaluate(T object);
}
public static interface Iterator<T> {
public void iterate(Closure<T> closure, Predicate<T> predicate);
}
public static class TreeNode implements Iterator<TreeNode> {
private List<TreeNode> children = new ArrayList<TreeNode>();
public void iterate(Closure<TreeNode> closure, Predicate<TreeNode> predicate) {
if (predicate.evaluate(this)) closure.execute(this);
for (TreeNode child : children) child.iterate(closure, predicate);
}
}
public static <T> void iterateSorted(Iterator<T> iterator, Closure<T> closure, Predicate<T> predicate, Comparator<T> comparator) {
final List<T> temp = new ArrayList<T>();
iterator.iterate(new Closure<T>() { public void execute(T object) { temp.add(object); } }, predicate);
Collections.sort(temp, comparator); for (T node : temp) closure.execute(node);
}
public static void main(String [] args) {
iterateSorted(
new TreeNode(),
new Closure<TreeNode>() {
public void execute(TreeNode object) { System.out.println(object); }
},
new Predicate<TreeNode>() {
public boolean evaluate(TreeNode object) { return object != null; }
},
new Comparator<TreeNode>() {
public int compare(TreeNode x, TreeNode y) { return 0; }
});
}
}
S>Ок. Нельзя ли продемонстрировать применение такого механизма для выдачи, допустим, хотя бы тех же листьев дерева, отобранных по условию?
примерно также как код выше, только предикаты, замыкания и всякие утилиты там уже есть (правда называются немного подругому и чуть более обобщенные). т.е. достаточно пяти строчек кода, определяющий сам TreeNode.
Здравствуйте, Sinclair, Вы писали:
S>Прекрасная идея. В отличие от тупикового пути с замыканиями. S>Есть только одно "но": в отличие от дотнетной, эта реализация не "ленивая". Т.е. первое же обращение к Tree.getRoot().getAllChildren() приведет к почти полному обходу дерева — кроме листьев. Прелесть yield в том, что он исполняется по мере необходимости. К примеру, если я делаю CollectionHelper.Find(Tree.Root.AllChildren, ...), то обход прекратится сразу же, как только я найду нужный элемент.
К сожалению нет возможности узнать как внутренне реализован yeild и что внутри происходит, может просто весь стек рекурсии просто запрятан в недрах дотнета?. Насчет ленивой реализации, т.е. сделать так, чтобы итераторы добавлялись по мере исчерпания предыдущего, надо подумать выход должен быть, не такой простой конечно как в .Net.
Здравствуйте, Azix, Вы писали:
A>Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell. A>Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net. A>Не думаю, что Java может предложить что-то похожее.
Здравствуйте, Loafer, Вы писали:
L>Здравствуйте, Azix, Вы писали:
A>>Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell. A>>Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net. A>>Не думаю, что Java может предложить что-то похожее.
L>Ebay подойдет?
Здравствуйте, Azix, Вы писали:
A>Здравствуйте, Loafer, Вы писали:
L>>Здравствуйте, Azix, Вы писали:
A>>>Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell. A>>>Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net. A>>>Не думаю, что Java может предложить что-то похожее.
L>>Ebay подойдет?
A>Тогда просто миру не был доступен .Net.
Здравствуйте, Cyberax, Вы писали:
C>Azix wrote:
>> Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО >> НА Shared Source CLI Release
C>Из shared source там нет ни строчки кода — лицензия на shared source не C>позволяет. Mono'деятели все переписали с ноля.
CLI — стандартизирована и открыта, это означает то, что любой может реализовать ее. Microsoft открыла свою реализацию CLI, которая, кстати компилируется и работает не только под Windows, но еще и под FreeBSD.
Здравствуйте, Loafer, Вы писали: L>К сожалению нет возможности узнать как внутренне реализован yeild и что внутри происходит, может просто весь стек рекурсии просто запрятан в недрах дотнета?.
Да, конечно. Почему же нет? Смотришь рефлектором и все видишь. L> Насчет ленивой реализации, т.е. сделать так, чтобы итераторы добавлялись по мере исчерпания предыдущего, надо подумать выход должен быть, не такой простой конечно как в .Net.
Конечно же есть. Я же говорю — вместо каждого метода, возвращающего IEnumerable<T>, придется реализовать два класса. Просто сишарп это делает автоматически.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Sinclair, Вы писали:
S>>Гм. Ты не мог бы показать, как именно это сделать? Причем желательно, чтобы iterate() не зависел от TreeNode.
N>кстати, код ниже, ИМХО, лучше чем версия с мульти итератором хотябы тем, что не пораждает столькоже итераторов сколько ветвей у дерева. ну и позволяет частичную итерацию (достаточно бросить исключение в Closure или завести возвращаемое значение + флажок).
Ну да, несколько лучше. Но видишь ли в чем дело, тут у нас начинается фатальная негибкость. В принципе, можно получить похожую функциональность при помощи комбинирования замыканий.
Ты пошел по неверному пути, пытаясь сразу получить все возможные комбинации. К примеру, метод iterateSorted — неудачен, поскольку требует передать сразу все. А если нам не надо сортировку, а только фильтрацию?
S>>Ок. Нельзя ли продемонстрировать применение такого механизма для выдачи, допустим, хотя бы тех же листьев дерева, отобранных по условию?
N>примерно также как код выше, только предикаты, замыкания и всякие утилиты там уже есть (правда называются немного подругому и чуть более обобщенные). т.е. достаточно пяти строчек кода, определяющий сам TreeNode.
Ну вот мне и хотелось бы посмотреть на эти пять строчек. Хочу понять, что я теряю, не используя Java.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Loafer, Вы писали:
L>Здравствуйте, Azix, Вы писали:
A>>Здравствуйте, Loafer, Вы писали:
L>>>Здравствуйте, Azix, Вы писали:
A>>>>Понятия не имею, что там гоаорят, но знаю — ВСЕ ЭТО РАБОТАЕТ, ОСНОВАНО НА Shared Source CLI Release (у MS тоже исходные коды выкладываются, иногда , основано на стандартах и спонсировано Novell. A>>>>Можно даже на сайте посмотреть список крупных корпоративных проектов, написанных на кросс-платформенной версии .Net. A>>>>Не думаю, что Java может предложить что-то похожее.
L>>>Ebay подойдет?
A>>Тогда просто миру не был доступен .Net.
И о чем это говорит? О том, что кто-то выбрал Java? Ну это нормально, а что же теперь? Все должны разом перебегать на .Net?
Ну выбрали они Java — может денег сэкономили, может c Microsof'ом не дружат, может Solaris любят.
2005 год почти кончился, а вот это 2006-ой (будущее)!
бедный админы новела, мне их жаль искренне. серьезная контора никогда не будет вкладывать деньги в разработку софта базовая платформа которого может исчезнуть в любой момент по мановению Билли.
а release notes этого чуда смотрели? почитайте — страшно становится ну и там FAQ
Do you fear that Microsoft will change the spec and render Mono useless?
...
Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.
Azix wrote:
> C>Из shared source там нет ни строчки кода — лицензия на shared source не > C>позволяет. Mono'деятели все переписали с ноля. > CLI — стандартизирована и открыта, это означает то, что любой может > реализовать ее.
Я не спорю, именно это и сделали Mono'иды.
> Microsoft открыла свою реализацию CLI, которая, кстати компилируется и > работает не только под Windows, но еще и под FreeBSD.
А вот тут уже не совсем все так — лицензия на Rotor не позволяет
использовать его в коммерческих целях.
Здравствуйте, Sinclair, Вы писали:
S>Ну да, несколько лучше. Но видишь ли в чем дело, тут у нас начинается фатальная негибкость. В принципе, можно получить похожую функциональность при помощи комбинирования замыканий.
угу, так и делается. еще можно предикаты и компараторы комбинировать.
S>Ты пошел по неверному пути, пытаясь сразу получить все возможные комбинации. К примеру, метод iterateSorted — неудачен, поскольку требует передать сразу все. А если нам не надо сортировку, а только фильтрацию?
если сортировку ненадо, то просто вызываем метод iterate() у TreeNode. короче — все это уже вопрос дизайна API, можно его долго вылизывать чтобы был супер удобным, но yield тебя от этого не избавит.
S>Ну вот мне и хотелось бы посмотреть на эти пять строчек. Хочу понять, что я теряю, не используя Java.
с т.з. итераторов — точно ничего не теряешь, JGA переделывается на C# почти без изменений. например, вот такой код обойдет только уникальные ветви дерева сразу за которыми идут повторяющиеся ветви (т.е. из ветвей 1, 2, 3, 3, 4, 5, 5, 6, 6, 7 будут обходится только 3, 5, 6). closure будет вызвана для поддерева вне зависимости от результата предиката.
import java.util.*;
import net.sf.jga.fn.*;
import static net.sf.jga.util.Iterables.*;
import static net.sf.jga.util.Algorithms.*;
public class Test {
public static <T> Iterable<T> iterable(final Iterator<T> iterator) {
return new Iterable<T>() { public Iterator<T> iterator() { return iterator; } };
}
public static class TreeNode extends BinaryFunctor<UnaryFunctor<TreeNode, Boolean>, UnaryPredicate<TreeNode>, Boolean> {
private Collection<TreeNode> children = new ArrayList<TreeNode>();
public Boolean fn(UnaryFunctor<TreeNode, Boolean> closure, UnaryPredicate<TreeNode> predicate) {
for (TreeNode child : unique(iterable(findAdjacent(children)))) child.fn(closure, predicate);
return predicate.fn(this) && closure.fn(this);
}
}
}
Коллега.
Фанатизм никого не красит.
В Java без делегатов — плохо. Ну плохо. Можно жить, но все равно плохо. И никуда от этого не деться.
И доп. настройки GC в .net ввести все-таки заметно проще, чем делегаты в Java (Хотя лично мне они до одного места). Собственно, история с шаблонами в этом плане очень показательна.
Ну некрасивая это позиция "раз в наш супер-пупер открытый и настраиваемый язык этого не ввели, значит это никому не нужно". Другое это значит.
А по поводу Hibernate — штука знатная. И вообще — многое в Java внушает уважение ("Давно тут сидим" (с)). Но вот Asp.Net в наше время ни Java-е, ни кому-либо еще, противопоставить откровенно нечего. Разные весовые категории просто. А этот рынок сейчас едва ли не самый серьезный.
Вообще — M$ — монстр. Во всех смыслах, и плохих и хороших. Сильную штуку сделали.
Здравствуйте, mrozov, Вы писали:
M>В Java без делегатов — плохо. Ну плохо. Можно жить, но все равно плохо. И никуда от этого не деться.
расскажи чем делегат лучше чем анонимный класс? ну чемже?
new Comparator<A>() {
public int compare(A a, A b) { return 0; }
}
вот и делегат.
M>И доп. настройки GC в .net ввести все-таки заметно проще, чем делегаты в Java (Хотя лично мне они до одного места). Собственно, история с шаблонами в этом плане очень показательна.
а что, собственно, с шаблонами, кстати? настройки ЖЦ зря вам до одного места, оч полезная штука. хотя, конечно если простейшие формы лобать то не нужно это все.
M>Ну некрасивая это позиция "раз в наш супер-пупер открытый и настраиваемый язык этого не ввели, значит это никому не нужно". Другое это значит.
позиция — давайте в язык пришащим все что сможем придумать мне тожне не нравится — получится помойка.
M>А по поводу Hibernate — штука знатная. И вообще — многое в Java внушает уважение ("Давно тут сидим" (с)). Но вот Asp.Net в наше время ни Java-е, ни кому-либо еще, противопоставить откровенно нечего. Разные весовые категории просто. А этот рынок сейчас едва ли не самый серьезный.
кстати, лично я Hibernate совсем не уважаю и вообще большого смысла в ORM не вижу, но не суть. чем ваш хваленый ASP.NET лучше BEA WebLogic + нормальный IDE (хотябы даже бесплатный Eclipse с плагинами)? как раз в области web в Java есть столько всего — огромное кол-во веб серверов на все случаи жизни, огромное кол-во MVC frameworks на любой вкус, редакторы WISIWYG в т.ч. JavaScriptа, хитрые компоненты которые можно вставлять в страницы, поддержка AJAX... ИМХО, как раз ASP.NET ни в какое сравнение не идет с тем что дает Java.
mrozov wrote:
> Но вот Asp.Net в наше время ни Java-е, ни кому-либо еще, > противопоставить откровенно нечего. Разные весовые категории просто. А > этот рынок сейчас едва ли не самый серьезный.
Здравствуйте, mrozov, Вы писали: M>Но вот Asp.Net в наше время ни Java-е, ни кому-либо еще, противопоставить откровенно нечего. Разные весовые категории просто. А этот рынок сейчас едва ли не самый серьезный.
M>Вообще — M$ — монстр. Во всех смыслах, и плохих и хороших. Сильную штуку сделали.
Отсутствие знаний никого не красит. Смотреть Tapestry/JSF/Wicket
N>расскажи чем делегат лучше чем анонимный класс? ну чемже?
1. Компактностью.
2. Логичностью.
N>вот и делегат.
воти оверхед
N>а что, собственно, с шаблонами, кстати? настройки ЖЦ зря вам до одного места, оч полезная штука. хотя, конечно если простейшие формы лобать то не нужно это все.
С шаблонами — введение без изменения виртуальной машины. компромиссное решение. Тяжело уже в Java вводить что-то новое — по понятным причинам.
Да нет, не зря. Ровно по тем же причинам, по которым мне не зря написание своего варианта управления процесссами.
N>позиция — давайте в язык пришащим все что сможем придумать мне тожне не нравится — получится помойка.
Именно. Хороший пример — анонимные классы.
N>кстати, лично я Hibernate совсем не уважаю и вообще большого смысла в ORM не вижу,
о-о-о-о.
>Nно не суть. чем ваш хваленый ASP.NET лучше BEA WebLogic + нормальный IDE (хотябы даже бесплатный Eclipse с плагинами)? как раз в области web в Java есть столько всего — огромное кол-во веб серверов на все случаи жизни, огромное кол-во MVC frameworks на любой вкус, редакторы WISIWYG в т.ч. JavaScriptа, хитрые компоненты которые можно вставлять в страницы, поддержка AJAX... ИМХО, как раз ASP.NET ни в какое сравнение не идет с тем что дает Java.
Здравствуйте, mrozov, Вы писали:
M>1. Компактностью.
ну, право — несерьезно. учитывая то кол-во нажатий клавиш которое нужно в современных ИДЕ (к которым ВС с натягом относится). кроме того — анонимные классы функциональней, читабельней и вписываются в ОО.
M>2. Логичностью.
логичностью?? ссылка на метод это логично? даааа..
N>>вот и делегат. M>воти оверхед N>>позиция — давайте в язык пришащим все что сможем придумать мне тожне не нравится — получится помойка. M>Именно. Хороший пример — анонимные классы.
как раз анонимные классы намного лучше столь любимых вами делегатов. как минимум — если нужно определить сразу 2-3-Н методов или завести локальную переменную. как с делегатом сделать такое?
interface A {
int b();
int c();
}
new A() {
private int count;
public int b() {
return count++;
}
public int c() {
return count--;
}
}
вложенный класс делать?
M>С шаблонами — введение без изменения виртуальной машины. компромиссное решение. Тяжело уже в Java вводить что-то новое — по понятным причинам.
и что — какая разница как это сделано? зачем вообще ты вдаешься в подробность — изменилась ли виртуальная машина... чем на практике шаблоны плохо сделаны? зато байткод совместим, а в дотнете поди все библиотеки пересобирать пришлось?
а ДотНет легко вносить изменения потому что для него кода мало еще написано да и МС особенно о совместимости не думает — наколбасим а девелоперы пусть разбираются...
M>Понятно.
вот много кричат дотнетчики про то что АСП.НЕТ это наше все. но я так и не увидил ни одного аргумента в его пользу (хотя если спросить про то чем С# лучше заученно отвечают про делегаты). пожалуйста, расскадите про его уникальные фичи. очень интересно.
n0name2 wrote:
> и что — какая разница как это сделано? зачем вообще ты вдаешься в > подробность — изменилась ли виртуальная машина... чем на практике > шаблоны плохо сделаны? зато байткод совместим, а в дотнете поди все > библиотеки пересобирать пришлось?
Байткод обратно несовместим. Прямая совместимость есть и в .NET и в Java.
Здравствуйте, Cyberax, Вы писали:
C>Байткод обратно несовместим. Прямая совместимость есть и в .NET и в Java.
кстати, если способ байт код собранный под Java5 перенести под Java1.4. именно за счет того что шаблоны сделаны так а не иначе.
а в .NET можно сделать так (Java не умеет):
Здравствуйте, n0name2, Вы писали:
N>кстати, если способ байт код собранный под Java5 перенести под Java1.4. именно за счет того что шаблоны сделаны так а не иначе. N>а в .NET можно сделать так (Java не умеет):
N>
N>public static <T> T x() { return new T(); }
N>
Можно так:
public static T x<T>()
where T : new()
{
return new T();
}
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, anton_t, Вы писали:
S>>Если учесть, поверх чего работает .Net, то становится понятным, что .Net без хорошей поддержки нативного кода был бы просто не жилец. Так что гордиться такими вещами, как fixed и unsafe, на мой взгляд, довольно глупо. Они не от хорошией жизни были придуманы.
_>И поверх чего же работает .Net?
Как поверх чего? Поверх линуксов, макосов, фрибсдов да и майкрософтовских ос тоже...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, n0name2, Вы писали:
N>как раз анонимные классы намного лучше столь любимых вами делегатов. как минимум — если нужно определить сразу 2-3-Н методов или завести локальную переменную. как с делегатом сделать такое?
N>
N>interface A {
N> int b();
N> int c();
N>}
N>new A() {
N> private int count;
N> public int b() {
N> return count++;
N> }
N> public int c() {
N> return count--;
N> }
N>}
N>
очень просто. Вот допустим у нас был метод, куда мы собирались передавать твой анонимный класс:
public static void methodA(A ainstance);
вот так мы его вызывали ( я для компактности поменял выравнивание):
public static void test()
{
methodA(
new A()
{
private int count;
public int b() { return count++; }
public int c() { return count--; }
}
);
}
перепишем его на дотнет:
public delegate int A();
public static methodA(A b, A c);
и вызовем аналогичным твоему образом:
public static void Test()
{
int count;
methodA(
delegate { return count++; }
delegate { return count--; }
);
}
Если есть еще вопросы — пиши, не стесняйся.
Встречный вопрос: как мне воспроизвести на Java вот это:
а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет? или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.
S>
M>С шаблонами — введение без изменения виртуальной машины. компромиссное решение. Тяжело уже в Java вводить что-то новое — по понятным причинам.
В смысле? Существует ~200 языков под джава байт-код.Такие конструкции НЕТ-у и не снились: например, после каждого вызова методов Set* (регулярное выражение) у классов com.custom.util.JDBC* (Еще регулярное выражение) сделать то-то (это из АОП)
S>>Если есть еще вопросы — пиши, не стесняйся.
N>а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет?
Ничего страшного. Конечно же, этот случай предусмотрен. Замыкание, как и в джаве, стянет count на себя. Фрейм Test ему не нужен. N>или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.
Конечно же есть. Оно формируется неявно, захватывая те переменные из объемлющего scope, которые используются в анонимном делегате. S>>
S>>Как там у нас насчет композиции интерфейсов?
N>ну да, неплохо. хотя если нужно такое то я бы уже начал аспектами пользоватся. такие тулзы под .НЕТ есть? AspectWerkz
Спокойствие, только спокойствие. Тулзы — они и в африке тулзы. Пока что мы говорим о том, для чего нужны "эти бесполезные делегаты, которые во всем проигрывают анонимным классам". Как видно, анонимные классы позволяют немножко точнее и многословнее описывать состояние делегата, зато у них нет встроенной поддержки Multicast. Еще одна маленькая фишечка анонимных делегатов — дотнет угадывает сигнатуру. Обратил внимание, что я не стал писать ни параметров, ни возвращаемого значения? Даже если у делегата есть входные параметры, но мой анонимный делегат их не использует (а это сплошь и рядом так для стандартных обработчиков событий — какой-нибудь Click очень редко требует анализа sender или args), я могу не писать (object sender, EventArgs args) между delegate и {}. Тип возвращаемого значения выводится из того, что возвращает return, а поскольку делегаты в дотнете контравариантны, то я могу возвращать объекты более точного типа, чем ожидается.
Таким образом, в простых случаях делегаты несколько удобнее. Если прибавить к ним поддержку событий, которые автоматически реализуют подписку/отписку, то джава начинает смотреться бледновато.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Таким образом, в простых случаях делегаты несколько удобнее. Если прибавить к ним поддержку событий, которые автоматически реализуют подписку/отписку, то джава начинает смотреться бледновато.
короче убедил, в принципе действительно неплохая штука для всяких там OnClick, etc. в реальной жизни проекты на Жабе все больше используют IoC и собирают конечный код исходя из конфигурации заданной в аннотациях и отдельных файлах. все это позволяет довольно сильно снизить coupling и повысить расширяемость.
те кому в Жабном мире сильно нравятся всякие хитрые синтаксические фенечки давно перешли на Groovy. это такое расширение Жабы (код на чистой Жабе является подмножеством, даже плагины к IDE для него есть), позволяющего делать, например, следующее:
def xml = new NodeBuilder()
xml.customers() {
loc = 'London'
sql.eachRow("select * from customer where location = ${loc}) {
// lets process each row by emitting some markup
xml.customer(id:it.id, type:'Customer', foo:someVariable)) {
role(it.person_role)
name(it.customer_name)
location(id:it.location_id, name:it.location_name)
}
}
}
можно переопределять всякие там "+=" и делать композиции.. можно использовать одновременно жесткую типизацию и duck typing...
но лично мое мнение что синтаксические конструкции погоды не делают и при желании легко можно сделать расширение компилятора. гораздо большую роль играет наличие разнообразных библиотек, реализующих намного более нетривиальные вещи и возможность выбора реализации той или иной подсистемы исходя из нужд проекта (web server, application server, JVM, IDE, etc по соображениям цены/производительности/масштабируемости/управляемости и т.д.)
Здравствуйте, n0name2, Вы писали:
N>короче убедил, в принципе действительно неплохая штука для всяких там OnClick, etc.
Совершенно верно. N>в реальной жизни проекты на Жабе все больше используют IoC и собирают конечный код исходя из конфигурации заданной в аннотациях и отдельных файлах. все это позволяет довольно сильно снизить coupling и повысить расширяемость.
Это тоже cool, хотя выглядит разочаровывающим для click-click anyhow developer, т.к. заставляет его думать о вещах, о которых он думать и не собирался. Я согласен с тем, что такое думание очень поможет на более далеких этапах развития как проекта, так и его разработчика. Но на старте внимание отвлекают как раз такие микровещи, упрощающие жизнь. Люди-то хотят прямо так нарисовать About Box, и сразу его увидеть. А не изучать, где в XML файле нужно написать строчку для Copyright, и в каком локализованном ресурсе указать action "About...", и где прописать Action Handler, и понять что надо использовать именно <ModalDialogHandler dlgId="AboutDlg"/>, чтоб потом напустить на это MegaUIPreCompiler, который выкинет набор шаблонов для кодогенератора, который сгенерирует набор классов для UI, и в качестве побочного эффекта мы получим команду About.. в меню Help. Которая зато также доступа в диалоге Customize для тулбаров, клавиатуры, и контекстных меню, автоматически дизаблится в тех случаях, когда команда недоступна, и даже умеет записываться в макрос. Cool. Где мой Hello world?
Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется
А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.
N>те кому в Жабном мире сильно нравятся всякие хитрые синтаксические фенечки давно перешли на Groovy. это такое расширение Жабы (код на чистой Жабе является подмножеством, даже плагины к IDE для него есть), позволяющего делать, например, следующее: N>но лично мое мнение что синтаксические конструкции погоды не делают и при желании легко можно сделать расширение компилятора.
Это конечно же да — лишь бы за этим расширением стояла достаточная масса. Вот я, к примеру, с радостью и счастием возьму третий шарп на вооружение. А мегакомпилер от третьих фирм с теми же фичами, или даже большими — вряд ли. Потому как его дальнейшая судьба непредсказуема. Но в целом ты прав. К тому же дотнет прям-таки нарошно делался с прицелом на многоязычность. Я думаю, через пять лет мы просто будем по-быстрому ваять свое расширение шарпа под нужды конкретного проекта, и часть кода реализовывать на нем. N>гораздо большую роль играет наличие разнообразных библиотек, реализующих намного более нетривиальные вещи и возможность выбора реализации той или иной подсистемы исходя из нужд проекта (web server, application server, JVM, IDE, etc по соображениям цены/производительности/масштабируемости/управляемости и т.д.)
Это да. Наличие фреймворка — великая вещь. Ну, тут меня греет светлое будущее. Пока что задачи, которые мы решаем, не требуют особых application server и прочих hi-end технологий. А небольшие технологии, вроде O/R Mapping уже в наличии есть. Для enterprize приложений конечно дотнет пока что выглядит тоненькой оберткой над неуправляемым миром, по сравнению с гигантами Java.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Люди-то хотят прямо так нарисовать About Box, и сразу его увидеть.
ну так еще со времен дельфи/вб с этим особых проблем небыло. кстати, помню на дельфях мне и в голову не приходило использовать нечто вроде делегатов для обработки OnClick — вроде как ткнул в пропертиз и пиши код...
S>Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется
"не мы такие, жизнь такая..." (с) бумер
S>А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.
угу, мелочи а приятно. кстати, SQLJ (нечто вроде ЛИНКУ правда только для БД) уже был как-то в Жабе, почему-то не прижился, хотя эксгумировать можно...
S>Потому как его дальнейшая судьба непредсказуема.
вот это как раз одна из фундаментальных политик МС — юзай только наше и нишагу в сторону. мне она сильно не нравится. Сан себе такого не позволяет, иногда даже интегрирует сторонние продукты в core (например EJB3). бенчмарки новых процессоров (Niagara) публикует используя сторонний application server...
Здравствуйте, n0name2, Вы писали:
N>ну так еще со времен дельфи/вб с этим особых проблем небыло. кстати, помню на дельфях мне и в голову не приходило использовать нечто вроде делегатов для обработки OnClick — вроде как ткнул в пропертиз и пиши код...
Боюсь тебя разочаровать, но в дельфи как раз делегаты были с самого начала. Там не было поддержки мультикаста (что приходилось обходить через страшный геморрой — см. исходники TDataSource), но в целом очень похожая концепция. Фактически, делегат — это procedure of object на стероидах. Что, в общем-то, неудивительно, с учетом того, что у обеих фич один и тот же автор, только делегаты он сделал попозже. S>>Правильно, Hello World уже не нужен. Времена консоли пора забыть как страшный сон. Сейчас рулят плагины для Eclipse, Enterprize Java Beans и танковые клинья. Ну и тактическое ядерное оружие, разумеется
N>"не мы такие, жизнь такая..." (с) бумер
S>>А мне нравятся вот эти милые сердцу романтические мелочи. События, делегаты, дженерики. Заранее люблю LINQ и классы-хелперы.
N>угу, мелочи а приятно. кстати, SQLJ (нечто вроде ЛИНКУ правда только для БД) уже был как-то в Жабе, почему-то не прижился, хотя эксгумировать можно...
S>>Потому как его дальнейшая судьба непредсказуема.
N>вот это как раз одна из фундаментальных политик МС — юзай только наше и нишагу в сторону. мне она сильно не нравится.
Ничего подобного. Это моя личная политика. Просто я лично не очень жажду делать шаги в сторону. Хотя временами это напоминает необходимость иметь личный мерс, даже если твоя работа расположена на другой стороне той же улицы . N>Сан себе такого не позволяет, иногда даже интегрирует сторонние продукты в core (например EJB3). бенчмарки новых процессоров (Niagara) публикует используя сторонний application server...
Сан себе не позволяет большинство из развлечений МС по единственной банальной причине: у них не так много денег. Время покажет, был ли прав Билли, или все это — вложения в очень длинную интерактивную игру для MS Research
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Сан себе не позволяет большинство из развлечений МС по единственной банальной причине: у них не так много денег. Время покажет, был ли прав Билли, или все это — вложения в очень длинную интерактивную игру для MS Research
зато "бедность" сама породила здоровую конкуренцию в результате которой было открыто множество стартапов, созданы многомиллиардные рынки разнообразного ПО и т.д.
лично я считаю что будующее за открытыми стандартами и опен сорсом потому что "сила не в деньгах, сила в правде" (с) брат. рано или поздно Билли придется отказатся от жесткого вендор локинга (отчасти в Висте он к этому уже идет) или придется потихоньку брести на кладбище. нельзя десятки лет с наглой рожей плевать на всех и вся...
многие монополии МС потихоньку сдают позиции открытому софту (офис, браузер, может быть даже винда). особенно большие надежды я возлагаю на Red Flag Linux ну и на AJAX... по большому счету столь высокая доля рынка во многом обеспечивается пиратами, что будет если, скажем, вендоры железа сделают аппаратную поддержку самоуничтожения компа в случае попытки установки пиратской программы ? думаю, очень многие (по крайней мере в РФ) кинутся ставить Линух.
S>>Если есть еще вопросы — пиши, не стесняйся.
N>а если methodA асинхронный и count понадобится когда фрэйма Test уже давно не будет? или нужно много разных count а не один принадлежащий инстансу класса который это все вызывает? короче, нету у делегата собственного состояния.
Hint: closures
Насколько я понял, count будет в данной ситуации выделен в куче (как поле специального класса) и делегат просто неявно получает ссылку на экземпляр этого класса. При каждом вызове Test будет создан новый такой объект (по сути, это просто контекст).
А вот в Java замыканий (нормальных, а не этого угрёбища с final-переменными, где они просто копируются при создании экземпляра анонимного класса) нет и пока вроде не предвидится. Что очень печально. Приходится городить тонны классов и интерфейсов, там, где казалось бы можно обойтись простыми лямбда-функциями.
S>>
S>>Как там у нас насчет композиции интерфейсов?
N>ну да, неплохо. хотя если нужно такое то я бы уже начал аспектами пользоватся. такие тулзы под .НЕТ есть? AspectWerkz
Вот-вот. Это и есть "подход Java". Там, где в приличных языках требуется пара строчек, в Java используются жуткие генераторы, инструментация байт-кода, монструозные технологии и прочая дребедень
Здравствуйте, WFrag, Вы писали:
WF>Вот-вот. Это и есть "подход Java". Там, где в приличных языках требуется пара строчек, в Java используются жуткие генераторы, инструментация байт-кода, монструозные технологии и прочая дребедень
Подход Жабы, что те кто надо используют "жуткие генераторы, инструментация байт-кода, монструозные технологии". А тем кому не надо — клиент-сайду например, не парятся с изучением конструкций нужных в 1% случаев.
Здравствуйте, Dimonizhe, Вы писали:
D>Подход Жабы, что те кто надо используют "жуткие генераторы, инструментация байт-кода, монструозные технологии". А тем кому не надо — клиент-сайду например, не парятся с изучением конструкций нужных в 1% случаев.
1%? Как считали? Мне функций высшего порядка и замыканий постоянно не хватает, хотя на "функциональных" языках я практически и не писал. А вот анонимные классы я редко использую, потому что мситаю, что они читабельность сильно ухудшают.
Здравствуйте, WFrag, Вы писали:
WF>Вот-вот. Это и есть "подход Java". Там, где в приличных языках требуется пара строчек, в Java используются жуткие генераторы, инструментация байт-кода, монструозные технологии и прочая дребедень
где с делегатами нужно пара строчек, с анонимными классами четыре от силы. только вот "namespace {}" vs "package" уже выравниывет LOC. ну надумана проблема, несерьезно совершенно. кстати, ниче сложного и жуткого в инструментации байт кода не вижу. ей есть вполне достаточно применений которые никакими делегатами добится невозможно без изменения половины кода приложения. и рефлекшены напорядок быстрее работают если обертка сгенерирована..
хотя, конечно, не без греха — много софта понаписали что без бутылки не разберешься. но это скорее от излишнего усердия всяких фрэймворкописателей. но по сравнению с COM и его гемороем даже EJB кажутся простыми и понятными слава богу мне как Жаба программеру никогда не приходится с этой помойкой иметь дело (впрочем, я вообще UI не трогаю — не люблю это дело).
с другой стороны, на самом деле тотже Resin + JSP намного легче и проще IIS + ASP.NET. маленькое и простенькое приложение без тучи стародавних и ненужных фич IIS, в основном все на вообще на JSP делается даже без Жаба кода...
Здравствуйте, n0name2, Вы писали:
N>где с делегатами нужно пара строчек, с анонимными классами четыре от силы.
Да, только нужно еще и интерфейс описать. Который скорее всего больше нигде использоваться и не будет.
Например, есть некая древовидная структура, нужно из нее вытащить некоторые данные. Хорошим решением было бы что-то вроде (псевдо-код на непонятно чём ):
Где processHierarchy — функция обхода всего дерева. Вызывает второй параметр для каждого элемента их дерева (например, для каждого листа).
Вместо этого приходится писать полностью функцию обхода дерева для конкретного случая. Потому что вводить интерфейс/анонимный класс неохота — код будет еще страшнее, куча левых сущностей.
Здравствуйте, n0name2, Вы писали:
N>бедный админы новела, мне их жаль искренне. серьезная контора никогда не будет вкладывать деньги в разработку софта базовая платформа которого может исчезнуть в любой момент по мановению Билли.
А как это, стандарт ECMA отзовут, что-ли? CLI как платформа уже состоялась, проблема сейчас — портируемая GUI библиотека. Но и это будет.
Здравствуйте, SilverCloud, Вы писали:
SC>А как это, стандарт ECMA отзовут, что-ли? CLI как платформа уже состоялась, проблема сейчас — портируемая GUI библиотека. Но и это будет.
зачем отзывать то? выпустят новую версию с существенными отличаями от ECMA. не только GUI, главное это нечто вроде ASP.NET портируемого. я пока не вижу особенного рвения стандартизировать всю платформу .НЕТ. а CLI сам по себе никому по большому счету не интересен, нужно решение top to bottom...
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Причем тут — матрица или не-матрица? Ясно, что создание большого объекта в куче займет больше времение чем операция sub esp, <большой_размер_объекта>
Так для этого и делаются структуры. Многие вычисления приходится перекладывать на стек, иначе а. фрагментация памяти б. медленно
Здравствуйте, n0name2, Вы писали:
N>вообще, есть десяток реализаций DOM/SAX для Java, есть и более продвинутые/быстрые API (StAX, etc). а для .NET кто-то это делает? или MS демотивирует — мол есть наша им и пользуйся?
Это как ра и показывает, что все никако не могут один раз сделать, а делают поделки.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Dimonizhe, Вы писали:
D>>Подход Жабы, что те кто надо используют "жуткие генераторы, инструментация байт-кода, монструозные технологии". А тем кому не надо — клиент-сайду например, не парятся с изучением конструкций нужных в 1% случаев.
WF>1%? Как считали? Мне функций высшего порядка и замыканий постоянно не хватает, хотя на "функциональных" языках я практически и не писал. А вот анонимные классы я редко использую, потому что мситаю, что они читабельность сильно ухудшают.
Ура, наконец-то я в живую увидел этот один процент.
Здравствуйте, SilverCloud, Вы писали:
SC>Здравствуйте, n0name2, Вы писали:
N>>бедный админы новела, мне их жаль искренне. серьезная контора никогда не будет вкладывать деньги в разработку софта базовая платформа которого может исчезнуть в любой момент по мановению Билли.
SC>А как это, стандарт ECMA отзовут, что-ли? CLI как платформа уже состоялась, проблема сейчас — портируемая GUI библиотека. Но и это будет.
Задолбала эта мантра — будет в следующей версии, в следующем сервис паке, будет....будет....будет....будет.... Когда будет тогда и поговорим.
А сейчас говорите — нет, и неясно когда появиться.
Здравствуйте, slskor, Вы писали:
G_>>>>... чего есть в C# + .NET такого чего нет в Java? RB>>>ставит Java на место догоняющего. Это характерно, или так получилось??? G_>>Именно. Ведь .NET появился позже и обязан был по этой причине дать что-то новое.
S>В библиотеке классов Java много путаницы. Начинающих знакомиться с Java класс Date просто сводит с ума S>На мой взгляд, .NET имеет более продуманную библиотеку классов. Тот самый случай, когда чужой опыт и ошибки были учтены.
ИМХО перед проектировщиками java.* и System.* ставили разные приоритеты. В первом случае гибкость и простота имплементации во втором удобство использования. И те и другие по большей части своей цели добились. Хочется конечно и того и другого и лучше без хлеба но так не бывает...
Здравствуйте, TK, Вы писали:
TK>Скорее всего в яве не плодят дополнительных сущностей не потому, что структуры — те же классы, только на стеке, а потому, что ява это больше академический язык и начинающему студенту тяжело будет понять что такое структура, в чем она отличается от класса и почему в других языках появилась необходимость в данной конструкции.
TK>Да и по куче других отличий. TK>Возьмем те-же делегаты, что проще использовать для обработки событий? делегат или хитрую конструкцию из интерфейса, адаптера и класса наследника адаптера переопределяющего один/два метода. Понятно, что делегат проще, компактнее в записи и т.п. но, для ява программиста это означает, что нужно запомнить еще одну сущность. а это, может не укладываться в учебные планы, да и бедному ява программисту придется выделить лишний кусок своей драгоценной памяти из скудных запасов... отсюда мы и имеем — застой в платформе и цепляние за устоявшиеся стереотипы.
TK>)
Давай не будем так хвастливо гордится НЕакадемическим шарпом и .NET. Не будем забывать как майкрософт мечется, боясь не успеть ухватить сочный куш. Майскрософт вообще редко изобретает что-то новое и умное — в основном передирают зарекомендовавшие себя идеи — что и произошло с платформой .NET — идея Javы же родилась еще в начале 90-х — тогда это была еще не Java, а Oak — но главное идея. Майсрософт же попыталась поддерживать Java в своей студии — Visual J++ Схватилась — не пошло — потом бросила это дело и давай придумывать то же самое, но свое, но с опозданием на 5-6 лет по сравнению с Javой — молодцы — копировать умеем. Благо денег полно — можем очень быстро и много кода напедалить и обернуть в красивую обертку в которой ни одной новой идеи.
К слову идея Окон тоже содрана из Мас OS. И много примеров можно привести — но вопрос не об этом. Вопрос в том как долго платформа .NET будет соответсвовать современным каконам — ведь в любую технолигию нужно развивать — расширять — дополнять новыми идеями — будет ли майкрософт успевать копировать новые идеи? (чтиобы скопировать идею Java им понадобилось 5 лет — это много или мало?)
Здравствуйте, E., Вы писали:
E.>Давай не будем так хвастливо гордится НЕакадемическим шарпом и .NET. Не будем забывать как майкрософт мечется, боясь не успеть ухватить сочный куш. Майскрософт вообще редко изобретает что-то новое и умное — в основном передирают зарекомендовавшие себя идеи — что и произошло с платформой .NET — идея Javы же родилась еще в начале 90-х — тогда это была еще не Java, а Oak — но главное идея. Майсрософт же попыталась поддерживать Java в своей студии — Visual J++ Схватилась — не пошло — потом бросила это дело и давай придумывать то же самое, но свое, но с опозданием на 5-6 лет по сравнению с Javой — молодцы — копировать умеем. Благо денег полно — можем очень быстро и много кода напедалить и обернуть в красивую обертку в которой ни одной новой идеи.
А вот Вирт утверждает, что Java содрана с оберона. Выходит, что Sun "молодцы — копировать умеем. Благо денег полно — можем очень быстро и много кода напедалить и обернуть в красивую обертку в которой ни одной новой идеи."?
E.>К слову идея Окон тоже содрана из Мас OS. И много примеров можно привести — но вопрос не об этом.
Окна не только в винде и маке есть. Однако в воровстве идей ты обвиняешь только майкрософт.
E.>Вопрос в том как долго платформа .NET будет соответсвовать современным каконам — ведь в любую технолигию нужно развивать — расширять — дополнять новыми идеями — будет ли майкрософт успевать копировать новые идеи?
Небольшой пример: генерики появились в яве только после того, как майкрософт заявил их появление в дотнет.
E.>(чтиобы скопировать идею Java им понадобилось 5 лет — это много или мало?) E.>
.Net это ответ на Java, но с чего ты взял, что чистая копия?
Здравствуйте, ihatelogins, Вы писали:
I>Здравствуйте, jdev333, Вы писали:
J>>имхо, микрософт может не управиться в конкурентное время с платформой J>>как я понимаю до сих пор нету аналога серверов приложений, а они уже сейчас сами по себе отходят на второй план — посмотрите что делают SAP, Oracle, IBM, BEA и др. (уже) — портал + warehouse + integration broker + app_server- переход к сервисной архитектуре (не путать с веб-сервисами)
I>Очень похоже на маркетинговый бред.
Вспоминает анекдот. Дура то дура, а свои $200 в день имею. Бред — не бред, а сегмент рунка — громадный.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Здравствуйте, GarryIV, Вы писали:
GIV>>Про Date ты прав на 100% — крыша уехала мигом
ДЦ> А к слову — что там с классом Date?
Как без танцев с бубном вычислить разницу между двумя датами?
Здравствуйте, anton_t, Вы писали:
_>.Net это ответ на Java, но с чего ты взял, что чистая копия?
если бы была чистой копией, то не сливала бы с позором серверной JVM в два раза на простейшей пузырьковой сортировке привет структурам в качестве прититивов...
_>Как без танцев с бубном вычислить разницу между двумя датами?
import java.util.*;
import static java.lang.System.*;
import static org.apache.commons.lang.time.DurationFormatUtils.*;
public class Test2 {
public static void main(String[] args) {
out.println(formatDurationWords(new GregorianCalendar().getTimeInMillis() - new GregorianCalendar(2004, 1, 1).getTimeInMillis(), true, true));
}
}
Денис Цыплаков wrote: > Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что > я видел
Она была бы самой удобной, если бы класс java.util.Date был
иммутабельным (как String).
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
Наверное правильный ответ — ощущение того, что Java это охренительный рынок на котором все проблемы решаются. Причем решаются без привлечения Sun. Ты всегда знаешь, что никогда не попадешь в зависимость от отсутствия в платформе какой-то фичи. Или от ошибки в платформе. Все можно обойти, на все можно найти решение. Всегда есть другой путь. Или в крайнем случае можно разобраться и сделать самому, благо для деланья самим везде есть соотвествующие зацепочки. А если даже и нет, что все равно можно сделать.
Здравствуйте, Cyberax, Вы писали:
C>Денис Цыплаков wrote: >> Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что >> я видел C>Она была бы самой удобной, если бы класс java.util.Date был C>иммутабельным (как String).
Денис Цыплаков wrote: >> > Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что >> > я видел > C>Она была бы самой удобной, если бы класс java.util.Date был > C>иммутабельным (как String). > Возможно. Но чем мешает мутабельность Date?
Не совсем логично получается. Date как обертка над число миллисекунд —
это фактически "безразмерная" величина (одинаковая во всех часовых
поясах), но в класс Date добавили методы для разбора дат, установки
дней/минут/лет, которые зависят от локали. Потом они исправились, и
сделали класс Calendar
Здравствуйте, Cyberax, Вы писали:
C>Денис Цыплаков wrote: >>> > Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что >>> > я видел >> C>Она была бы самой удобной, если бы класс java.util.Date был >> C>иммутабельным (как String). >> Возможно. Но чем мешает мутабельность Date? C>Не совсем логично получается. Date как обертка над число миллисекунд — C>это фактически "безразмерная" величина (одинаковая во всех часовых C>поясах), но в класс Date добавили методы для разбора дат, установки C>дней/минут/лет, которые зависят от локали. Потом они исправились, и C>сделали класс Calendar
А! это! Тут как раз самое интересно. Если подходить концептуально — то да, ты прав. Разработчики Явы пошли путем отделения данных от процессоров. Но не дошли а остановились. Момент это конечно спорный. Вроде как концептуально не красиво. Но не надо забывать что
1. Есть в Java классах тяжелое наследие JDK 1.0, помеченное как deprecated
2. Удобно когда класс с данными предоставляет некоторую базовую функциональность для доступа к себе. На мой взгляд в Яве классы данных нигде за эту самую базовость не выходят. Опять же в календарь венесены операции которые могут различаться в зависомсти от типа календаря (Грегорианский календарь не единственный). А в Date только что что неразрывно связано с датой.
3. Есть в дизайне Явовских классов некоотрая золотая середина. Но это аргумент сугубо субъективный. Я эту середину вижу, но не факт, что ее видит кто-то еще.
В любом случае то, что было перечисленно не тянет уезжание крыши. Ну никак.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Здравствуйте, anton_t, Вы писали:
ДЦ>>> А к слову — что там с классом Date?
_>>Как без танцев с бубном вычислить разницу между двумя датами?
ДЦ>
ДЦ> Date d1;
ДЦ> Date d2;
ДЦ> System.out.println(d1.getTime() - d2.getTime());
ДЦ>
ДЦ> в миллисекундах. Если надо в чем-то еще — дели, форматируй. ДЦ> Есть класс Calendar для арпифметики и т.п.
ДЦ> Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что я видел
А вот когда я из этого количества миллисекунд попытался сделать нормальную дату и она получилась на 7 часов больше чем надо, это мне не показалось сколько-нибудь удобным.
Здравствуйте, anton_t, Вы писали:
_>А вот когда я из этого количества миллисекунд попытался сделать нормальную дату и она получилась на 7 часов больше чем надо, это мне не показалось сколько-нибудь удобным.
А всё потому, что диапазон /между двумя датами/ и сама дата это две большие разницы.
Здравствуйте, anton_t, Вы писали:
_>Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>>
ДЦ>> Date d1;
ДЦ>> Date d2;
ДЦ>> System.out.println(d1.getTime() - d2.getTime());
ДЦ>>
ДЦ>> Я как раз считаю что реализацию даты в Яве наиболее удобная из всего что я видел
_>А вот когда я из этого количества миллисекунд попытался сделать нормальную дату и она получилась на 7 часов больше чем надо, это мне не показалось сколько-нибудь удобным.
Может быть в консерватории что-то подправить. Разница между датами и и собственно дата это разные величины. Если ты скажешь что именно надо и как делал — подскажу как надо.
Например так
Date d1;
Date d2;
long delta = d1.getTime() - d2.getTime();
long days = delta / 1000 / 60 / 60 /24;
delta = delta - days;
long hours = delta / 1000 / 60 / 60;
delta = delta - hours;
long minutes = delta / 1000 / 60;
delta = delta - minutes;
long sec = delta / 1000;
long mces = delta - sec;
System.out.println ( "delta = " + days + " дн " + hours + " ч " + minutes + " мин " + sec + " сек " + msec + " мс" );
Ну если с нуля и руками то так. А вообще-то можно и проще. Есть апачевские классы которые это дело сильно упрощают.
Здравствуйте, Денис Цыплаков, Вы писали:
_>>А вот когда я из этого количества миллисекунд попытался сделать нормальную дату и она получилась на 7 часов больше чем надо, это мне не показалось сколько-нибудь удобным.
Тут вот спрашивали — чем Ява лучше. Тем например — что есть свобода выбора и хорошего выбора.
Вот например для тех кому не нравится родная Явовская дата можно использовать вот такую библиотеку. Хотя меня например родная дата устраивает.
Joda-Time 1.2 - Replacing JDK Date and Calendar
Joda-Time 1.2 has been released. Joda-Time provides a Java library for date and time handling including the ISO8601 standard. It completely replaces the JDK Date and Calendar classes, while still providing good integration. This release fixes some minor bugs in v1.1 and adds two new calendars as well as some useful new methods on existing classes. It is open-source software under the ASF2 license.
This release fixes a number of minor bugs in v1.1. There are also some new features:
* Islamic calendar system
* Ethiopic calendar system
* YearMonthDay/TimeOfDay factory methods to ensure exact field by field creation from Date/Calendar
* simpler conversion of a month/week etc to an interval - dt.monthOfYear().toInterval()
* convenient method for getting last day of month - dt.monthOfYear().withMaximumValue()
Release notes: http://sourceforge.net/project/shownotes.php?release_id=379940&group_id=97367
Download: http://sourceforge.net/project/showfiles.php?group_id=97367&package_id=104212
Hibernate and JSP integration are available from linked websites.
Major features of Joda-Time
---------------------------
* Easy to Use - Calendar makes accessing 'normal' dates difficult, due to the lack of simple methods. Joda-Time has straightforward field accessors. And the index of January is 1!
* Extensible - Joda-Time supports multiple calendar systems via a plugin mechanism, which is much more extensible than the subclasses of Calendar. Currently supported calendars are ISO8601, GregorianJulian, Buddhist (Thai), Coptic, Ethiopic and Islamic.
* Comprehensive - Joda-Time includes classes for datetimes, dates without times, times without dates, intervals and time periods.
* Advanced formatting - An advanced and extensible formatting mechanism is included, allowing input and output to string in a thread-safe manner.
* Well documented. There is documentation in the form of a quick and full user guide, plus reference pages, FAQs and javadoc.
* Tested. There is good test coverage, see the website, providing an assurance of quality.
E.>Давай не будем так хвастливо гордится НЕакадемическим шарпом и .NET. ... E.>К слову идея Окон тоже содрана из Мас OS. И много примеров можно привести... E.>
Ничто не ново.
Окна — мак тоже передрал. Весь интерфейс вообще начался от IT&T (по-моему) или что-то в это роде в лохматых 60-х.
А по-поводу того, что мечется. То пусть. Чем больше мечется, тем больше рождается чего-то нового.
MS вообще своими метаниями двигает прогресс вперед. Пусть при этом много отпадает в виде шелухи. Но не замечать
того, что благодаря MS движение только ускоряется — это значит невидеть дальше кончика своего носа
Нельзя застаиваться. Нельзя останавливаться. Хотя многим этого хочется, но этого не будет. Во-многом благодаря MS.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Может быть в консерватории что-то подправить. Разница между датами и и собственно дата это разные величины. Если ты скажешь что именно надо и как делал — подскажу как надо. ДЦ> Например так
Теперь сравни с .NET
WolfHound wrote: > DateTime d1 = DateTime.Now; > Thread.Sleep(1212); > DateTime d2 = DateTime.Now; > TimeSpan d = d2-d1; > Console.WriteLine("delta = " + d.Days + " дн " + d.Hours + " ч " + d.Minutes + " мин " + d.Seconds + " сек " + d.Milliseconds + " мс");
Неправильно, на самом деле. Во-первых, а если я захочу астрономические
дни (23 часа 56 минут сколько-то секунд)? А еще надо учитывать leap
second, из-за которой в минуте может быть 61 секунда (или 59 секунд).
А как быть с переходом на зимнее/летнее время? Типа по "настенным часам"
разница будет 2 часа, а здесь получится 3 часа.
В общем, промежуток времени лучше всего представлять в виде
секунд/миллисекунд, так как даже минуты уже зависят от контекста в
котором промежуток дат интерпретируется.
Здравствуйте, Cyberax, Вы писали:
C>Неправильно, на самом деле. Во-первых, а если я захочу астрономические C>дни (23 часа 56 минут сколько-то секунд)? А еще надо учитывать leap C>second, из-за которой в минуте может быть 61 секунда (или 59 секунд).
Может сначала возьмешь рефлектор и посмотришь как реализован TimeSpan?..
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WolfHound wrote: > C>Неправильно, на самом деле. Во-первых, а если я захочу астрономические > C>дни (23 часа 56 минут сколько-то секунд)? А еще надо учитывать leap > C>second, из-за которой в минуте может быть 61 секунда (или 59 секунд). > Может сначала возьмешь рефлектор и посмотришь как реализован TimeSpan?..
Посмотрел. Как я и думал — обычное деление, без учета временных зон.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Может быть в консерватории что-то подправить. Разница между датами и и собственно дата это разные величины.
Вообще-то я знаю.
ДЦ>Если ты скажешь что именно надо и как делал — подскажу как надо. ДЦ> Например так
ДЦ>
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote: >> C>Неправильно, на самом деле. Во-первых, а если я захочу астрономические >> C>дни (23 часа 56 минут сколько-то секунд)? А еще надо учитывать leap >> C>second, из-за которой в минуте может быть 61 секунда (или 59 секунд). >> Может сначала возьмешь рефлектор и посмотришь как реализован TimeSpan?.. C>Посмотрел. Как я и думал — обычное деление, без учета временных зон.
anton_t wrote: >> > C>Неправильно, на самом деле. Во-первых, а если я захочу астрономические >> > C>дни (23 часа 56 минут сколько-то секунд)? А еще надо учитывать leap >> > C>second, из-за которой в минуте может быть 61 секунда (или 59 секунд). >> > Может сначала возьмешь рефлектор и посмотришь как реализован TimeSpan?.. > C>Посмотрел. Как я и думал — обычное деление, без учета временных зон. > А при чём тут временные зоны?
Представьте, что сейчас 00:00 в 04:00 происходит переход на летнее
время, так что после 04:59 часы снова покажут 04:00, но уже ЛЕТНЕГО
времени. Как мне в этом случае логичнее представить TimeSpan — как 4
часа или как 5 часов?
Или еще один вариант. 31 декабря, leap second — в последней минуте будет
61 секунда.
В общем, единственная надежная величина, на которую можно полагаться —
это секунда (а также милли-, микро- и прочие секунды).
Здравствуйте, Cyberax, Вы писали:
C>Представьте, что сейчас 00:00 в 04:00 происходит переход на летнее C>время, так что после 04:59 часы снова покажут 04:00, но уже ЛЕТНЕГО C>времени. Как мне в этом случае логичнее представить TimeSpan — как 4 C>часа или как 5 часов?
C>Или еще один вариант. 31 декабря, leap second — в последней минуте будет C>61 секунда.
C>В общем, единственная надежная величина, на которую можно полагаться — C>это секунда (а также милли-, микро- и прочие секунды).
Ну так никто не запрещает получить количество секунд из одной даты, количество из другой и потом делать с ними что душа пожелает. Однако если надо быстро по-простому — пожалуйста — TimeSpan.
anton_t wrote: > C>В общем, единственная надежная величина, на которую можно полагаться — > C>это секунда (а также милли-, микро- и прочие секунды). > Ну так никто не запрещает получить количество секунд из одной даты, > количество из другой и потом делать с ними что душа пожелает. Однако > если надо быстро по-простому — пожалуйста — TimeSpan.
Это не "по-простому", а просто небольшой сахарок над секундами, то же
самое делается классом из десяти строк.
Здравствуйте, anton_t, Вы писали:
ДЦ>> Ну если с нуля и руками то так. А вообще-то можно и проще. Есть апачевские классы которые это дело сильно упрощают.
_>Я же просил — без танцев с бубном.
Гм. Ну я уже не знаю. Если это танцы с бубном. Видимо
разница между .Net и Явой в философии мышления. Это как
разные биологические виды. То что кажется нормальным разработчикам
одной платформы не нравится разработчикам другой. И наоборот.
Например разработчики пишушие на Яве могут гнуть пальцы
А сколько для .Net есть
лог подсистем, библиотек O/R мапинга, библиотек XML Persistence, встраиваемых RDBMS
На что разработчики .Net могут отвечать нет и не надо. Или есть одно от MS. MS о нас заботится и делат одно супер правильное решение. Оно же самое верное.
В ответ разработчики .Net могут спросить — а есть для Java IDE которая позволяла бы рисовать GUI и нормально писать код — на что Ява разратчики смутятся и скажут нет. Ну рисовать GUI можно в NetBeans — но писать код в ней невозможно. Ужасная IDE почти так же неудобно кодировать как в Visual Studio. Визарды какие-то нелепые и т.п.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Здравствуйте, ihatelogins, Вы писали:
I>>Здравствуйте, jdev333, Вы писали:
J>>>имхо, микрософт может не управиться в конкурентное время с платформой J>>>как я понимаю до сих пор нету аналога серверов приложений, а они уже сейчас сами по себе отходят на второй план — посмотрите что делают SAP, Oracle, IBM, BEA и др. (уже) — портал + warehouse + integration broker + app_server- переход к сервисной архитектуре (не путать с веб-сервисами)
I>>Очень похоже на маркетинговый бред.
ДЦ> Вспоминает анекдот. Дура то дура, а свои $200 в день имею. Бред — не бред, а сегмент рунка — громадный.
Ну так, астрологи тоже ведь свой хлеб с маслом имеют.
Здравствуйте, ihatelogins, Вы писали:
I>Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>> Вспоминает анекдот. Дура то дура, а свои $200 в день имею. Бред — не бред, а сегмент рунка — громадный.
I>Ну так, астрологи тоже ведь свой хлеб с маслом имеют.
10.000.000 лемингов не могут ошибаться. Очень уж сегмент рынка у SAP + IBM + Oracle от астрологов отличается.
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> 10.000.000 лемингов не могут ошибаться. Очень уж сегмент рынка у SAP + IBM + Oracle от астрологов отличается.
Не знаю как вам, а нам с лемингами не по пути. Очень уж холодной воды не люблю
Кстати, и миллиарды мух тоже не могут ошибаться
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Здравствуйте, ihatelogins, Вы писали:
I>>Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>>> Вспоминает анекдот. Дура то дура, а свои $200 в день имею. Бред — не бред, а сегмент рунка — громадный.
I>>Ну так, астрологи тоже ведь свой хлеб с маслом имеют.
ДЦ> 10.000.000 лемингов не могут ошибаться. Очень уж сегмент рынка у SAP + IBM + Oracle от астрологов отличается.
У САП и Оракл есть один простой фактор, который им позволил так прижится в корпоративном секторе — это НЕРЕАЛЬНО высокая стоимость их продуктов. Которая просто озолотила средний и высший менеджмент. Сап — это чисто откатная технология. С технологической точки зрения их продукты — это позапрошлый век.
IBM — самая коррумпированная IT-компания в мире. Они это и не скрывают. Любая фитюля у них стоит ОТ МИЛЛИОНА. 10 тысяч идёт на зарплату индусам, а 990 делят заказчик и менеджер из IBM. "Технология", конечно, супер.
ihatelogins пишет:
> У САП и Оракл есть один простой фактор, который им позволил так прижится > в корпоративном секторе — это НЕРЕАЛЬНО высокая стоимость их продуктов. > Которая просто озолотила средний и высший менеджмент. Сап — это чисто > откатная технология. С технологической точки зрения их продукты — это > позапрошлый век.
Угу. А у микрософта с .Net такого фактор нет. МС — самая теплая,
пушистая и самое главное не желающая заработать деньги так же как
САП и IBM фирма. Так?
Ну в самом деле САП зарабатывает кучу бабок — МС уж я думаю знает
как это делается, но вот беда — то-ли не умеет, то-ли не хочет
зарабатывать деньги так-же?
Я правильно понял?
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
anton_t пишет:
> ДЦ> 10.000.000 лемингов не могут ошибаться. Очень уж сегмент рынка у SAP > + IBM + Oracle от астрологов отличается. > > Не знаю как вам, а нам с лемингами не по пути. Очень уж холодной воды не > люблю > Кстати, и миллиарды мух тоже не могут ошибаться
В принципе я шутил. Забыл смайлик поставить. Видимо без смайла — не
понятно, что шутка
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>anton_t пишет:
>> ДЦ> 10.000.000 лемингов не могут ошибаться. Очень уж сегмент рынка у SAP >> + IBM + Oracle от астрологов отличается. >> >> Не знаю как вам, а нам с лемингами не по пути. Очень уж холодной воды не >> люблю >> Кстати, и миллиарды мух тоже не могут ошибаться
ДЦ> В принципе я шутил. Забыл смайлик поставить. Видимо без смайла — не ДЦ> понятно, что шутка
А вам, видимо, без смайла не понятно, что я тоже шутил.
Денис Цыплаков wrote: > А! это! Тут как раз самое интересно. Если подходить концептуально — то > да, ты прав. Разработчики Явы пошли путем отделения данных от > процессоров. Но не дошли а остановились. Момент это конечно спорный.
Еще в Date другая проблема — представьте, что я беру ее из ResultSet'а
из DB и модифицирую. Получается как-то нелогично.
> 1. Есть в Java классах тяжелое наследие JDK 1.0, помеченное как deprecated
Я об этом и говорю
> 3. Есть в дизайне Явовских классов некоотрая золотая середина. Но это > аргумент сугубо субъективный. Я эту середину вижу, но не факт, что ее > видит кто-то еще.
Я считаю большую часть дизайна достаточно неплохой. Хотя некоторые не
очень умные решения там есть (а где их нет?).
Cyberax пишет: >> А! это! Тут как раз самое интересно. Если подходить концептуально — то >> да, ты прав. Разработчики Явы пошли путем отделения данных от >> процессоров. Но не дошли а остановились. Момент это конечно спорный. > Еще в Date другая проблема — представьте, что я беру ее из ResultSet'а > из DB и модифицирую. Получается как-то нелогично.
Может я просто молодой, а может на дизайне не зациклился. Ну
модифицируется, ну и что. Ну то-есть плохо конечно но не фатально.
Лично я вообще от этого дсикомфорта не испытываю. В свое время делал
библиотеку, а ней был базовый класс — носитель данных, у него были
скажем так способы защиты от изменений. Но как оценил потом неудобств
было больше чем достоинств. Выбросил сделал POJO
>> 3. Есть в дизайне Явовских классов некоотрая золотая середина. Но это >> аргумент сугубо субъективный. Я эту середину вижу, но не факт, что ее >> видит кто-то еще. > Я считаю большую часть дизайна достаточно неплохой. Хотя некоторые не > очень умные решения там есть (а где их нет?).
Что-бы оценить качество дизайна — надо попробовать сделать лучше
хотя бы в какой-то части. Я пробовал, проникся уважением к Sun
Легко сказать здесь вот метод надо сделать по другому. Но какие
будут последствия для 1000000 других разработчиков?
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>ihatelogins пишет:
>> У САП и Оракл есть один простой фактор, который им позволил так прижится >> в корпоративном секторе — это НЕРЕАЛЬНО высокая стоимость их продуктов. >> Которая просто озолотила средний и высший менеджмент. Сап — это чисто >> откатная технология. С технологической точки зрения их продукты — это >> позапрошлый век.
ДЦ> Угу. А у микрософта с .Net такого фактор нет. МС — самая теплая, ДЦ> пушистая и самое главное не желающая заработать деньги так же как ДЦ> САП и IBM фирма. Так?
ДЦ> Ну в самом деле САП зарабатывает кучу бабок — МС уж я думаю знает ДЦ> как это делается, но вот беда — то-ли не умеет, то-ли не хочет ДЦ> зарабатывать деньги так-же?
ДЦ> Я правильно понял?
Нет, не правильно. МС зарабатывает большие бабки из-за огромного кол-ва лицензий, а оракл/сап — дороговизной одной лицензии. Сап/оракл модель просто сделана для откатов. ТАК химичить на микрософте не получится.
Денис Цыплаков wrote: >> Еще в Date другая проблема — представьте, что я беру ее из ResultSet'а >> из DB и модифицирую. Получается как-то нелогично. > Может я просто молодой, а может на дизайне не зациклился. Ну > модифицируется, ну и что.
А если этот Date еще кто-то потом получит? Насколько я знаю, именно
поэтому многие реализации JDBC-драйверов создают новые копии Date'а.
>> Я считаю большую часть дизайна достаточно неплохой. Хотя некоторые не >> очень умные решения там есть (а где их нет?). > Что-бы оценить качество дизайна — надо попробовать сделать лучше > хотя бы в какой-то части.
Еще можно сравнить с другими существующими решениями. Например, STL из
С++ мне нравится больше чем коллекции из Java. Точнее, разделение между
контейнерами и алгоритмами, которое достигается применением итераторов.
Хотя, конечно, полностью все идиомы из STL в Java перенести не
получилось бы.
Ну и мелкие недостатки есть: типа спутаных абстракций связных списков и
векторов.
> Легко сказать здесь вот метод надо сделать по другому. Но какие > будут последствия для 1000000 других разработчиков?
А это надо было думать до начала разработки исходной версии.
Здравствуйте, ihatelogins, Вы писали:
I>Нет, не правильно. МС зарабатывает большие бабки из-за огромного кол-ва лицензий, а оракл/сап — дороговизной одной лицензии. Сап/оракл модель просто сделана для откатов. ТАК химичить на микрософте не получится.
большое кол-во лицензий у МС только на винду (десктопную) и офис. в тех областях где работают САП и Оракл инсталляций от МС зачастую даже меньше. не путай ситуацию в РФ и в цивилизованном мире. у нас все лицензии (да и все остальное) покупаются с откатами, в европе и штатах такое не пройдет. а МС пользуем без откатов только по причине огромного процента пиратства.
n0name2 wrote: > > I>Нет, не правильно. МС зарабатывает большие бабки из-за огромного > кол-ва лицензий, а оракл/сап — дороговизной одной лицензии. Сап/оракл > модель просто сделана для откатов. ТАК химичить на микрософте не получится. > > большое кол-во лицензий у МС только на винду (десктопную) и офис. в тех > областях где работают САП и Оракл инсталляций от МС зачастую даже > меньше. не путай ситуацию в РФ и в цивилизованном мире. у нас все > лицензии (да и все остальное) покупаются с откатами, в европе и штатах > такое не пройдет. а МС пользуем без откатов только по причине огромного > процента пиратства.
В Европе и Штатах есть другие методы стимуляции спроса. Например,
крупный заказчик Мелкософта может рассчитывать на _существенную_ скидку,
при условии, если он будет использовать продукты Мелкософта везде, где
только можно, вместо продуктов конкурентов.
Да и насчет откатов я не уверен. Да при покупке на 5 тысяч откат вряд ли
имеет место. Но кто знает, какие механизмы стоят за сделками на десятки
миллионов долларов? Во всяком случае, ясно, что детали никто не
афиширует
Здравствуйте, Pzz, Вы писали:
Pzz>Да и насчет откатов я не уверен. Да при покупке на 5 тысяч откат вряд ли Pzz>имеет место. Но кто знает, какие механизмы стоят за сделками на десятки Pzz>миллионов долларов? Во всяком случае, ясно, что детали никто не Pzz>афиширует
ну, как сказать — там финансовая отчетность открытая и хорошо аудируемая. записать серьезному интегратору или самому САПу в статью "представительские расходы" серьезную сумму и не отчитаться за нее перед акционерами не получится.
хотя, прециденты конечно были. многие из них закончились посадкой такого рода деятелей. и вообще — уж про корпоративную этику поклонникам МС стоит молчать в тряпочку. незря Билли выписывают рекордные штрафы, незря. и суды они один за другим проигрывают...
Здравствуйте, n0name2, Вы писали:
N>ну, как сказать — там финансовая отчетность открытая и хорошо аудируемая. записать серьезному интегратору или самому САПу в статью "представительские расходы" серьезную сумму и не отчитаться за нее перед акционерами не получится.
N>хотя, прециденты конечно были. многие из них закончились посадкой такого рода деятелей. и вообще — уж про корпоративную этику поклонникам МС стоит молчать в тряпочку. незря Билли выписывают рекордные штрафы, незря. и суды они один за другим проигрывают...
Я вот до сих пор не понимаю, почему медиа плэйер нельзя вместе с осью поставлять. Причём только майкрософту.
ihatelogins пишет:
> Нет, не правильно. МС зарабатывает большие бабки из-за огромного кол-ва > лицензий, а оракл/сап — дороговизной одной лицензии. Сап/оракл модель > просто сделана для откатов. ТАК химичить на микрософте не получится.
Гм. В общем-то у Микрософта тоже есть не дешевые продукты.
Весьма я бы сказал не дешевые
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
n0name2 wrote: > > Pzz>Да и насчет откатов я не уверен. Да при покупке на 5 тысяч откат вряд ли > Pzz>имеет место. Но кто знает, какие механизмы стоят за сделками на десятки > Pzz>миллионов долларов? Во всяком случае, ясно, что детали никто не > Pzz>афиширует > > ну, как сказать — там финансовая отчетность открытая и хорошо > аудируемая. записать серьезному интегратору или самому САПу в статью > "представительские расходы" серьезную сумму и не отчитаться за нее перед > акционерами не получится.
Я, конечно, не специалист, но взятку можно дать очень по-разному.
Например, можно разместить крупный заказ на фирме, принадлежащей тому,
кто получает взятку — и все будет совершенно законно.
Тут недавно показали по телевизору сюжет про то, что американские
военные закупают алюминиевые лесенки, по которым забираются механики,
обслуживающие истребители, по цене больше килобакса за штучку. При том
что точно такие же лесенки в хозяйственном магазине стоят что-то порядка
50 долларов. Это что, пример честного бизнеса?
anton_t wrote: > > N>хотя, прециденты конечно были. многие из них закончились посадкой > такого рода деятелей. и вообще — уж про корпоративную этику поклонникам > МС стоит молчать в тряпочку. незря Билли выписывают рекордные штрафы, > незря. и суды они один за другим проигрывают... > > Я вот до сих пор не понимаю, почему медиа плэйер нельзя вместе с осью > поставлять. Причём только майкрософту.
Потому, что:
1. Раз медиа плейер приходит вместе с осью, судьба других медиа
плейеров будет весьма незавидной — кто будет заморачиваться их ставить?
2. В медиа плейере hardcoded те места, откуда эту самую медию можно
скачивать. Значит, судьба других мест незавидна — кто будет их
специально искать?
Тем самым, Микрософт получает слишком много влияния в свои руки. И уж
точно, использует это влияние в своих интересах.
Только вот по-моему итоги суда, который обязал Миксософт поставлять
версию Виндовса без плейера, какие-то бессмысленные. Кому он нужен без
плейера, если с плейером стоит практически столько же?
Здравствуйте, Pzz, Вы писали:
Pzz>Я, конечно, не специалист, но взятку можно дать очень по-разному. Pzz>Например, можно разместить крупный заказ на фирме, принадлежащей тому, Pzz>кто получает взятку — и все будет совершенно законно.
там законодательство по другому трактуется. даже если тебе премию совершенно законно и вбелую выдали все равно можно доказать что ты получил ее с помощью махинаций. короче — были и есть такие деятели. но, там это единичные случаи не делающие погоды в общей массе продаж, чего не скажешь про РФ где на Аксапте не меньшие откаты получаются.
Здравствуйте, E., Вы писали:
E.>Здравствуйте, Sheridan, Вы писали:
S>>Здравствуйте, Joker6413, Вы писали:
J>>>Поглядим что через пару лет будет .
S>> S>>Поглядим-посмотрим, угу...
E.>Да именно следующая пара лет как раз будет определяющей в завоевании Windows серверного рынка.
Дааа... А потом они придумают язык C$, и новую технологию @work и скажут что .net нам теперь неинтересен вместе с C#, это уже устарело. А воот в C$ а нас ...! Вы сможете ...!!! А @work лучше .net потомучто ...!! Поэтому ...! Ваша компания ... инвестиции ... прибыль ... !!!! Давайте денюжку. Pzz тут хорошо сказал в Re[16]: Linux как хороший способ сэкономить по-честному
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Pzz, Вы писали:
Pzz>>Да и насчет откатов я не уверен. Да при покупке на 5 тысяч откат вряд ли Pzz>>имеет место. Но кто знает, какие механизмы стоят за сделками на десятки Pzz>>миллионов долларов? Во всяком случае, ясно, что детали никто не Pzz>>афиширует
N>ну, как сказать — там финансовая отчетность открытая и хорошо аудируемая. записать серьезному интегратору или самому САПу в статью "представительские расходы" серьезную сумму и не отчитаться за нее перед акционерами не получится.
Тебе расписать детально как откаты берутся или сам поймёшь? Отследить их через финансовую отчётность невозможно.
Здравствуйте, ihatelogins, Вы писали:
I>Здравствуйте, jdev333, Вы писали:
J>>имхо, микрософт может не управиться в конкурентное время с платформой J>>как я понимаю до сих пор нету аналога серверов приложений, а они уже сейчас сами по себе отходят на второй план — посмотрите что делают SAP, Oracle, IBM, BEA и др. (уже) — портал + warehouse + integration broker + app_server- переход к сервисной архитектуре (не путать с веб-сервисами)
I>Очень похоже на маркетинговый бред.
А сервера приложений 5 лет назад Вам бредом не казались?
Сейчас сервера приложений мутируют в продвинутое миддлвэре
Здравствуйте, ihatelogins, Вы писали:
I>Тебе расписать детально как откаты берутся или сам поймёшь? Отследить их через финансовую отчётность невозможно.
как я понимаю, производится продажа продуктов и услуг по завышенной стоимости. потом из средств поставщика происходит выдача отката в том или ином виде лицу или группе лиц принимающих решения о закупках. в отчетности поставщик обязан отразить все свои затраты, соот-но аудит его отчетности покажет неоправданно высокие расходы. почему невозможно отследить то? если брать только отчетность получателя — то да, сложно. но в тойже отчетности в нормальных конторах должны быть результаты конкурса, выдержки из прайс листов потенциальных поставщиков. серьезный аудит и это вполне может вскрыть.
N>но в тойже отчетности в нормальных конторах должны быть результаты конкурса, выдержки из прайс листов потенциальных поставщиков. серьезный аудит и это вполне может вскрыть.
Для крупных клиентов чаще всего не бывает прайс листов. И цена рассчитывается индивидуально. А вот тут бескрайнее поле для откатов.
И конкурсы все подделываются.
Кстати, у американского солдата пластиковая кружка, входящая в амуницию, стоит 50 уе за штуку... Очень видимо хайтековская кружка...
Nikolay_Ch пишет:
> N>но в тойже отчетности в нормальных конторах должны быть результаты > конкурса, выдержки из прайс листов потенциальных поставщиков. серьезный > аудит и это вполне может вскрыть. > Для крупных клиентов чаще всего не бывает прайс листов. И цена > рассчитывается индивидуально. А вот тут бескрайнее поле для откатов. > И конкурсы все подделываются. > Кстати, у американского солдата пластиковая кружка, входящая в амуницию, > стоит 50 уе за штуку... Очень видимо хайтековская кружка...
Ха. Кружка. Молоток на БМП Бреди стоит $800.
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Гм. В общем-то у Микрософта тоже есть не дешевые продукты. ДЦ> Весьма я бы сказал не дешевые
Ну, на этом рынке они еще дети. Международные Деловые Машины уж больше века окучивают корпоративный сектор
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Dimonizhe, Вы писали:
D>Задолбала эта мантра — будет в следующей версии, в следующем сервис паке, будет....будет....будет....будет.... Когда будет тогда и поговорим.
D>А сейчас говорите — нет, и неясно когда появиться.
Здравствуйте, Pzz, Вы писали:
Pzz>Тут недавно показали по телевизору сюжет про то, что американские Pzz>военные закупают алюминиевые лесенки, по которым забираются механики, Pzz>обслуживающие истребители, по цене больше килобакса за штучку. При том Pzz>что точно такие же лесенки в хозяйственном магазине стоят что-то порядка Pzz>50 долларов. Это что, пример честного бизнеса?
У нас круче — в соседнем форуме кто-то хвастался что у них в офисе пластмассовые кресла за штуку баксов
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
VD>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете?
Ну например приведите пример решения для РАСПРЕДЕЛЕННОГО кеша для .NET.
Здравствуйте, EM, Вы писали:
EM>Здравствуйте, VladD2, Вы писали:
VD>>Gregory_krovosos сравнивал Шарп с Явой как языки и как рантайм подсистемы. Так что мой вопрос остается в силе. Что полезного в Яве в этом смылсе, чего нет в дотнете?
EM>Ну например приведите пример решения для РАСПРЕДЕЛЕННОГО кеша для .NET.
EM>А для Java пожалуйста:
EM>http://www.tangosol.com/coherence.jsp EM>http://www.gemstone.com
EM>А вещь это мягко говоря немаловажная. И самому ее в жизни не написать.
Вообще-то asp.net умеет session state хранить как внутри своего процесса, так и в специалльном сервере, и в ms sql'е.
Уважаемые бойцы священного фронта!
Вот затеял я найти каие-нибудь материалы по вопросу сравнения .NET и Java. Какие-нибудь серьезные материалы, с аргументами за и против, с плюсами и минусами и т.п. Нужно это мне.
И ничего внятного не нашел. Возможно, такие материалы и есть, но оны похоронены под многими тысячами постов во всевозможных форумах (не только на этом). Яндекс и Гугл находят только сообщения, общий смысл абсолютного большинства которых можно выразить буквально двумя-тремя фразами :"NET — мастдай, Java — рулез", или "NET — рулез, Java — отстой", или "Автор ничего не понимает", или "Сам дурак".
Граждане, объясните мне, зачем Вы это пишете? Вам так сильно нечего делать? Зачем писать заведомую, абсолютно неаргументированную эмоциональную чушь? Почему бы вместо этого самым умным не написать хотя бы одну-две человеческих статьи на эту тему?
Вы меня, конечно, извините, но Ваши "войны" сильно напоминают написание различных слов на заборах.
SB> Вы меня, конечно, извините, но Ваши "войны" сильно напоминают написание различных слов на заборах.
И так понятно, что принципиальной разницы мало, зачем выкапывать тему почти трехлетней давности?
Здравствуйте, StarBears, Вы писали: SB> Граждане, объясните мне, зачем Вы это пишете? Вам так сильно нечего делать? Зачем писать заведомую, абсолютно неаргументированную эмоциональную чушь? Почему бы вместо этого самым умным не написать хотя бы одну-две человеческих статьи на эту тему?
Люди, способные провести объективное сравнение, не испытывают в том особого желания. Обратное, к сожалению, тоже в основном справедливо
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, StarBears, Вы писали:
SB> Уважаемые бойцы священного фронта! SB> Вот затеял я найти каие-нибудь материалы по вопросу сравнения .NET и Java. Какие-нибудь серьезные материалы, с аргументами за и против, с плюсами и минусами и т.п. Нужно это мне. SB> И ничего внятного не нашел. Возможно, такие материалы и есть, но оны похоронены под многими тысячами постов во всевозможных форумах (не только на этом). Яндекс и Гугл находят только сообщения, общий смысл абсолютного большинства которых можно выразить буквально двумя-тремя фразами :"NET — мастдай, Java — рулез", или "NET — рулез, Java — отстой", или "Автор ничего не понимает", или "Сам дурак". SB> Граждане, объясните мне, зачем Вы это пишете? Вам так сильно нечего делать? Зачем писать заведомую, абсолютно неаргументированную эмоциональную чушь? Почему бы вместо этого самым умным не написать хотя бы одну-две человеческих статьи на эту тему? SB> Вы меня, конечно, извините, но Ваши "войны" сильно напоминают написание различных слов на заборах.
Здравствуйте, Farsight, Вы писали: F>.NET 3.0 это 2.0 + несколько foundation. Тут.
Если брать во внимание не только платформы, но и языки, то тут(.doc, 337KB) и более "языко-независимо" тут
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, Gregory_krovosos, Вы писали:
G_>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
Атрибуты. Делегаты. Теперь уже и лямбда, а скоро и вывод типов появится (в кастрированном варианте, но лучше чем ничего). А в Java есть только кандалы и костыли. Кандалы — чтоб низкоквалифицированные "программисты" бед не наделали, а костыли — от безысходности.
Но вообще надо сравнивать CLI и JVM а не языки. Тут JVM вообще никакой критики не выдержит.
G_>Что на ваш взгляд является главным недостатком Java?
Здравствуйте, Silver_s, Вы писали:
S_> Дело наверно не в синтаксисе. Ну допустим сделают на Явовой платформе язык с синтаксисом C#, ну и рантайм изменят для новых фичей, от этого она не перестанет быть Явой.
Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком.
S_> А так идеи одни и те же у Явы и .NET,
Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно.
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Silver_s, Вы писали:
GNU> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком.
Какие фичи, например, "не потянет"?
GNU> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно.
смеялсо
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Gregory_krovosos, Вы писали:
G_>>Начать можно со такого вопроса — чего есть в C# + .NET такого чего нет в Java? Принимается все — начиная от конструкций языка и заканчивая технологиями и скоростями работы.
GNU> Атрибуты. Делегаты. Теперь уже и лямбда, а скоро и вывод типов появится (в кастрированном варианте, но лучше чем ничего). А в Java есть только кандалы и костыли. Кандалы — чтоб низкоквалифицированные "программисты" бед не наделали, а костыли — от безысходности.
GNU> Но вообще надо сравнивать CLI и JVM а не языки. Тут JVM вообще никакой критики не выдержит.
G_>>Что на ваш взгляд является главным недостатком Java? GNU> Сам факт её существования.
Судя по высказываниям, автор не утрудил себя даже поверхностным обзором java.
Здравствуйте, GNUzaurus, Вы писали:
S_>> Дело наверно не в синтаксисе. Ну допустим сделают на Явовой платформе язык с синтаксисом C#, ну и рантайм изменят для новых фичей, от этого она не перестанет быть Явой. GNU> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком.
Запросто потянет. В чем проблема то? Гораздо более интересные языки чем C# держит и ничего (Scala)
GNU> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно.
Читай больше агиток от MS по утрам Этот аргумент ихние маркетологи высосали из пальца. Получилось весьма забавно, но еще смешнее что этот флаг подхватили вроде бы умные люди...
Здравствуйте, Alexandro, Вы писали:
GNU>> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком. A>Какие фичи, например, "не потянет"?
Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу.
GNU>> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно. A>смеялсо
Ну смейсо, смейсо. Это ты наверное по малоопытности и недознанию смеёссо. А вот попробовал бы ты реализовать, допустим, Standard ML под JVM и под .NET — не смеялся бы, а плакал, горькими слезами. Да ладно там SML, даже просто нормальный (на переходах, а не таблицах) компилятор FSM построить — уже нереально, благодаря дебильному и ничем не обоснованному ограничению на размер методов.
Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада.
Здравствуйте, n0name2, Вы писали:
GNU>> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком.
N>Запросто потянет. В чем проблема то? Гораздо более интересные языки чем C# держит и ничего (Scala)
В том и дело, что ничего... Ничего хорошего. Scala — тормоз. На JVM невозможно эффективно реализовывать функциональщину. А на .NET — как два байта переслать.
GNU>> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно.
N>Читай больше агиток от MS по утрам Этот аргумент ихние маркетологи высосали из пальца.
Чувачок, ты хотя бы три-четыре компилятора написал? Если нет — то не имеешь права на подобный тон. Каждый имеет право говорить только о том, в чём он разбирается.
N> Получилось весьма забавно, но еще смешнее что этот флаг подхватили вроде бы умные люди...
В JVM нет хвостовой рекурсии. В .NET есть. В JVM нет структур, явно выделяемых на стеке — в .NET есть. В JVM есть лимит на размер методов — явно следующий из привязки к модели разработки на убогом язычке Java — в .NET такого предела нет.
Здравствуйте, Alexandro, Вы писали:
G_>>>Что на ваш взгляд является главным недостатком Java? GNU>> Сам факт её существования.
A>Судя по высказываниям, автор не утрудил себя даже поверхностным обзором java.
Смешное ты существо. Я под JVM около десятка разнообразных компиляторов написал. Для Java я писал source->source трансляторы и системы статического анализа кода. Я, в отличии от тебя, малограмотного, очень даже хорошо знаю, о чём говорю.
Здравствуйте, GNUzaurus, Вы писали:
G_>>Что на ваш взгляд является главным недостатком Java?
GNU> Сам факт её существования.
Лично мне, по большому счету, пофиг на чем писать, на .Net или Java,
но чем тебя лично не устроил факт ее сущестования? На чем бы ты писал
компиляторы 5-10 лет назад? Зачем вообще на ней писал? Какие альтернативы?
Здравствуйте, aka50, Вы писали:
GNU>> Сам факт её существования.
A>Лично мне, по большому счету, пофиг на чем писать, на .Net или Java, A>но чем тебя лично не устроил факт ее сущестования?
Она заняла очень привлекательную экологическую нишу, и в результате там
теперь не появится уже ничего более достойного. И когда приходится ориентироваться
на рынки, пересекающиеся с нишей Жабы — то приходится мириться и с её многочисленными
и непреодолимыми недостатками.
A> На чем бы ты писал компиляторы 5-10 лет назад?
На том же, на чём писал и 15 лет назад, и на чём пишу сейчас, и на чём писать буду ещё
лет 10 — на Common Lisp. Под любой таргет, мне в принципе по фигу, умеет ли рантайм сам мусор
собирать, да и graph coloring написать мне не в падлу, так что под x86 компилять не сильно сложнее
чем под стековые виртуальные машины.
A> Зачем вообще на ней писал?
На ней — за безальтернативностью платформы. Если клиенту нужен J2EE, то будет ему J2EE. Но
пусть не удивляется, наблюдая 10е правило Гринспуна в действии. А уж J2ME — и вовсе
безальтернативщина.
A> Какие альтернативы?
Полно их. Но они все занимают другие экологические ниши.
За то и присматриваюсь к .NET, что у него хотя бы есть некоторые шансы потеснить Жабку.
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, aka50, Вы писали:
GNU>>> Сам факт её существования.
A>>Лично мне, по большому счету, пофиг на чем писать, на .Net или Java, A>>но чем тебя лично не устроил факт ее сущестования?
GNU> Она заняла очень привлекательную экологическую нишу, и в результате там GNU>теперь не появится уже ничего более достойного. И когда приходится ориентироваться GNU>на рынки, пересекающиеся с нишей Жабы — то приходится мириться и с её многочисленными GNU>и непреодолимыми недостатками.
Теперь смысл высказывания понятен. Но с другой стороны, clisp же существовал и до java
и в разы мощнее... но ведь не прижился. Может все таки она не так плоха?
A>> Какие альтернативы? GNU> Полно их. Но они все занимают другие экологические ниши.
В том и суть, что другие. Т.е. в данном случае Java занимает свою, довольно обширную
нишу условной кроссплатформенности с низким порогов вхождения. Что в этом плохого?
GNU> За то и присматриваюсь к .NET, что у него хотя бы есть некоторые шансы потеснить Жабку.
И будет очень плохо, т.к. последствия потеснения разнообразия ОС мы уже наблюдаем http://rsdn.ru/Forum/Message.aspx?mid=2278420
осталось еще и все программирование загнать под одного вендора — и тогда можно будет сушить
весла... При этом если честно, не очень понимаю, почему бы не попытаться помочь тому же сану
(с учетом GPL-ти) реализовать недостающие вещи в JVM. Исходники то есть. А вот где
брать исходники и как вообще влиять на MS.Net ума не приложу...
Здравствуйте, aka50, Вы писали:
A>Теперь смысл высказывания понятен. Но с другой стороны, clisp же существовал и до java A>и в разы мощнее... но ведь не прижился. Может все таки она не так плоха?
Плоха, ещё как плоха. Только очень плохие продукты завоёвывают массовую популярность.
Java хороша в одном — она ПРИМИТИВНА. Как грабли. Потому она и сделала возможным использовать труд
очень посредственных программистов в промышленных масштабах. С Common Lisp это было бы невозможно, для
него порог вхождения очень нехилый нужен. Но как технология он на порядки превосходит и Java, и C#. А вот
как инструмент для массового производства он никуда не годится, с этим никто и не спорит. Потому и сравниваю
Жабу с C# — последний тоже для посредственных и дешевых кодеров подходит, но технологически на голову выше Жабы
стоит, и не так сильно выкручивает руки настоящим, сильным программистам.
A>>> Какие альтернативы? GNU>> Полно их. Но они все занимают другие экологические ниши. A>В том и суть, что другие. Т.е. в данном случае Java занимает свою, довольно обширную A>нишу условной кроссплатформенности с низким порогов вхождения. Что в этом плохого?
Плохо то, что она слишком уж поганая. В эту нишу можно было засунуть и более адекватную технологию. Ту же Java, но
с вменяемой виртуальной машиной.
GNU>> За то и присматриваюсь к .NET, что у него хотя бы есть некоторые шансы потеснить Жабку. A>И будет очень плохо, т.к. последствия потеснения разнообразия ОС мы уже наблюдаем http://rsdn.ru/Forum/Message.aspx?mid=2278420
Здравствуйте, Вертер, Вы писали:
GNU>> Сам факт её существования.
В>извиняюсь конечно, но если бы не было Java, вы бы навряд ли бы увидели .NET технологию
Не факт. Был бы .NET. Может, получше нынешнего, смоделированный глядя на Inferno и Smalltalk...
GNU>>> Сам факт её существования.
В>>извиняюсь конечно, но если бы не было Java, вы бы навряд ли бы увидели .NET технологию
GNU>Не факт. Был бы .NET. Может, получше нынешнего, смоделированный глядя на Inferno и Smalltalk...
извините, а сколько лет Smalltalk и почему раньше МС его в упор не видела?!
ответ прост, очень давно Гейтс как-то сказал, что мы ориентируемся только на такой рынок, где можем продать миллион копий (думаю и о уровне доходов он имел ввиду). Так вот Java где-то там и была со своими технологиями, поэтому МС и решила "пододвинуть" Java. Одна сплошная выгода завёрнутая в красивый фантик
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, GNUzaurus, Вы писали:
S_>>> Дело наверно не в синтаксисе. Ну допустим сделают на Явовой платформе язык с синтаксисом C#, ну и рантайм изменят для новых фичей, от этого она не перестанет быть Явой. GNU>> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком.
N>Запросто потянет. В чем проблема то?
Тут уже некоторые писали:
В простоте и эффективности реализации других языков. Возьмем к примеру Python. Jython медленее CPython, а IronPython наоборот, почти в 2 раза быстрее. Есть ли в Java аналоги System.CodeDom и System.Reflection.Emit?
N>Гораздо более интересные языки чем C# держит и ничего (Scala)
Ну, во-первых Scala бывает весьма ощутимо тормозит:
We haven't yet gone very far into evaluating those thingies
(nemerle is dotnet and dotnet offers very far reaching possibilities to
emit code at runtime, Java is a bit clumsy and middle-ages in that respect)
(здесь)
GNU>> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно.
N>Читай больше агиток от MS по утрам Этот аргумент ихние маркетологи высосали из пальца. Получилось весьма забавно, но еще смешнее что этот флаг подхватили вроде бы умные люди...
Нет, MS учел уроки Java и создал более технологически совершенный .NET. Я не фанат MS и мне больше нравится то что Java под GPL, но тем не менее это так. И практически во всех тестах MS.NET быстрее Java (здесь писал в ФП).
Здравствуйте, GNUzaurus, Вы писали:
GNU>>> За то и присматриваюсь к .NET, что у него хотя бы есть некоторые шансы потеснить Жабку. A>>И будет очень плохо, т.к. последствия потеснения разнообразия ОС мы уже наблюдаем http://rsdn.ru/Forum/Message.aspx?mid=2278420
A>>осталось еще и все программирование загнать под одного вендора — и тогда можно будет сушить A>>весла...
GNU> Mono.
Только не надо об этом поделии в хвосте паровоза... Иказа пусть сначала MC и Гном
доделает, а потом уже за глобальные вещи берется. Да и не пользовали его еще массово,
вот када запользуют я посмотрю на их багтрак. Не, нафиг. Лучше "убогий" сан
чем "великий" Иказа...
Здравствуйте, GNUzaurus, Вы писали:
GNU> Java хороша в одном — она ПРИМИТИВНА. Как грабли. Потому она и сделала возможным использовать труд GNU>очень посредственных программистов в промышленных масштабах. С Common Lisp это было бы невозможно, для GNU>него порог вхождения очень нехилый нужен. Но как технология он на порядки превосходит и Java, и C#. А вот GNU>как инструмент для массового производства он никуда не годится, с этим никто и не спорит. Потому и сравниваю GNU>Жабу с C# — последний тоже для посредственных и дешевых кодеров подходит, но технологически на голову выше Жабы GNU>стоит, и не так сильно выкручивает руки настоящим, сильным программистам.
Это просто развитие Java. Sun действует эволюционно, MS — революционно. Не факт, что
второй подход лучше.
A>> При этом если честно, не очень понимаю, почему бы не попытаться помочь тому же сану A>>(с учетом GPL-ти) реализовать недостающие вещи в JVM.
GNU> Проблемы с дизайном. Нерешаемые.
Пополз в сторону кладбища....
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Вертер, Вы писали:
GNU>>> Сам факт её существования.
В>>извиняюсь конечно, но если бы не было Java, вы бы навряд ли бы увидели .NET технологию
GNU>Не факт. Был бы .NET. Может, получше нынешнего, смоделированный глядя на Inferno и Smalltalk...
Эээ... Ну так на .NET Smalltalk вполне живет (см. хотя бы Vista Smalltalk), так что можно сказать что он включает его в себя как подмножество. А Inferno (а точнее даже его прародитель Plan9)... Там скорее интересны находки в плане протокола 9P, но при чем здесь архитектура фреймворка подобного .NET/JRE .
Здравствуйте, Андрей Хропов, Вы писали:
АХ>В простоте и эффективности реализации других языков. Возьмем к примеру Python. Jython медленее CPython, а IronPython наоборот, почти в 2 раза быстрее. Есть ли в Java аналоги System.CodeDom и System.Reflection.Emit?
Этого нет из-за необходимости городить класс (т.е. можно в рантайме конечно родить код,
но он обязан быть классом, это умеют делать BCEL, CGLIB и javassist.
АХ>Нет, MS учел уроки Java и создал более технологически совершенный .NET. Я не фанат MS и мне больше нравится то что Java под GPL, но тем не менее это так. И практически во всех тестах MS.NET быстрее Java (здесь писал в ФП).
Очень надеюсь, что все таки GPL и давление .Net подтолкнет слегка Sun в этом направлении .
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Alexandro, Вы писали:
GNU>>> Для этого надо рантайм жабский менять кардинально. Сейчас она просто не потянет. Ограниченная слишком. A>>Какие фичи, например, "не потянет"?
GNU> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу.
большие методы прекрасно разделяются компилятором на мелкие. делегаты = интерфейс + анонимный класс. где тут потеря производительности? INTPTN — каюсь, не знаю что это. и гугл не знает. Нативные вызовы? jni. Другая архитектура и переносимо. Так что действительно лучше вовсе помолчать.
GNU>>> Нет. .NET изначально делался под как можно более широкое разнообразие языков и технологий. JVM же годится ТОЛЬКО для Java. Ничего кроме Java нельзя реализовать эффективно. A>>смеялсо
GNU> Ну смейсо, смейсо. Это ты наверное по малоопытности и недознанию смеёссо. А вот попробовал бы ты реализовать, допустим, Standard ML под JVM и под .NET — не смеялся бы, а плакал, горькими слезами. Да ладно там SML, даже просто нормальный (на переходах, а не таблицах) компилятор FSM построить — уже нереально, благодаря дебильному и ничем не обоснованному ограничению на размер методов.
мда, а мужики то не знают, что нельзя и реализуют здесь. Хотя секция ML пуста.
GNU> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада.
Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Alexandro, Вы писали:
G_>>>>Что на ваш взгляд является главным недостатком Java? GNU>>> Сам факт её существования.
A>>Судя по высказываниям, автор не утрудил себя даже поверхностным обзором java.
GNU> Смешное ты существо. Я под JVM около десятка разнообразных компиляторов написал. Для Java я писал source->source трансляторы и системы статического анализа кода. Я, в отличии от тебя, малограмотного, очень даже хорошо знаю, о чём говорю.
Я не опущусь до оскорбления таких ничтожеств как ты. Закончил.
Здравствуйте, Alexandro, Вы писали:
A>Здравствуйте, GNUzaurus, Вы писали:
GNU>> Например, делегаты (потянет только с огромнейшей потерей производительности). A> делегаты = интерфейс + анонимный класс. где тут потеря производительности?
Это будет не совсем то. Есть даже RFE на его реализацию, и вроде как InProgress. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4191243
GNU>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
Тоже есть RFE. Там же можно прочитать про сложности реализации. (например в случае с security). http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726340
Здравствуйте, aka50, Вы писали:
GNU>>> Например, делегаты (потянет только с огромнейшей потерей производительности). A>> делегаты = интерфейс + анонимный класс. где тут потеря производительности? A>Это будет не совсем то. Есть даже RFE на его реализацию, и вроде как InProgress. A>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4191243
Опять же, возможна реализация delegate — эквивалентной функциональности в рамках jvm.
GNU>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно. A>Тоже есть RFE. Там же можно прочитать про сложности реализации. (например в случае с security). A>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726340
Согласен, хотя в IBM JVM эта фича реализована. здесь
Автор же говорил, что реализация подобных фич не возможна.
Если вернуться к предыдущей теме, в jvm невозможна реализация некоторых security-аспектов, как это сделано в .NET. Просто security в java реализована по другому.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>В простоте и эффективности реализации других языков. Возьмем к примеру Python. Jython медленее CPython, а IronPython наоборот, почти в 2 раза быстрее. Есть ли в Java аналоги System.CodeDom и System.Reflection.Emit?
Есть в Java6 compiler API javadoc
Если нужно — можно байткод напрямую генерировать и загружать.
С Python, думаю, опятьже дело в некорректных тестах (см ниже).
N>>Гораздо более интересные языки чем C# держит и ничего (Scala) АХ>Ну, во-первых Scala бывает весьма ощутимо тормозит: АХ>[Benchmark] Встроенный while vs макросы vs замыкания на Scala
Бенчмарк, как всегда, некорректен Не видел еще ни одного бенчмарка, который адепты C# написали бы корректно для Java или ее производных. В данном случае, не учтено время, которое тратит компилятор byte code -> native code. Вернее, оно не вынесено за рамки измерений.
Как минимум, нужно вставлять -Xcomp -Xbatch и результаты будут в разы лучше.
Хотя, именно в этом случае, просто наткнулись на баг в server JVM плюс то, что компилятор Scala не использует встроенный boolean тип.
АХ>
АХ>We haven't yet gone very far into evaluating those thingies
АХ>(nemerle is dotnet and dotnet offers very far reaching possibilities to
АХ>emit code at runtime, Java is a bit clumsy and middle-ages in that respect)
Ну, это уже не актуально с появлением compiler API.
АХ>Нет, MS учел уроки Java и создал более технологически совершенный .NET. Я не фанат MS и мне больше нравится то что Java под GPL, но тем не менее это так. И практически во всех тестах MS.NET быстрее Java (здесь писал в ФП).
Все эти т.н. "тесты" либо не учитывают то, что в начале работы происходит компиляция в native code, либо запускаются на client JVM, либо содержат другие грубые ошибки. Если все аккуратно и правильно сделать, то разницу можно увидеть только в конкретных местах, где нечто реализовано существенно по разному.
Например, примитивные типы данных работают быстрее в Java т.к. это не value типы, а отдельная сущность. А в некоторых случаях микробенчмарк можно завязать на value типы и он будет быстрее в .NET.
Или вот в последнем JDK сделали lock elimination/coalesce с помощью escape analysis. Теперь легко можно будет сделать бенчмарк в котором на синхронизации Java будет на порядок быстрее.
Из того, что я еще могу вспомнить — в Java гораздо более продвинутая memory model, которая позволяет компилятору делать очень много оптимизаций и собственно hotspot в то время как основную компиляцию в bytecode .NET делает один раз.
Короче, еще раз, по большей части песни о немеряном технологическом приемуществе .NET VM над JVM это чистый маркетинг. Корректный микробенчмарк сделать и запустить на JVM не так просто, но, она для этого и не предназначена.
Здравствуйте, GNUzaurus, Вы писали:
GNU> В JVM нет хвостовой рекурсии. В .NET есть. В JVM нет структур, явно выделяемых на стеке — в .NET есть. В JVM есть лимит на размер методов — явно следующий из привязки к модели разработки на убогом язычке Java — в .NET такого предела нет.
И это ты называешь технологическим приемуществом? Собственно, кроме хвостовой рекурсии ни одного более менее серьезного пункта. Хотя, это тоже вполне решаемый вопрос, если бы кому-то она была бы всерьез нужна — давно бы сделали.
Размер методов — стыдно вообще об этом упомянать, обходится элементарно, а stack allocation уже скоро будет в Sun JVM и уже есть в некоторых JVM, например, в Excelsior Jet. Причем, это будет прозрачно для программиста, не нужно будет использовать разные сущности для того, чтобы добится аллокации на стеке.
Если так подходить, то, у JVM есть свои технологические приемущества, актуальные для императивных языков — в Java есть примитивные типы данных, более эффективные чем структуры, в Java есть escape analysis, в Java есть hotspot машина, в Java есть быстрый biased locking и т.д.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>В простоте и эффективности реализации других языков. Возьмем к примеру Python. Jython медленее CPython, а IronPython наоборот, почти в 2 раза быстрее. Есть ли в Java аналоги System.CodeDom и System.Reflection.Emit?
N>Есть в Java6 compiler API javadoc N>Если нужно — можно байткод напрямую генерировать и загружать.
К тому же
1) Это только для Java. Для других языков пользы от этого 0.
2)
Package javax.tools Description
Provides interfaces for tools which can be invoked from a program, for example, compilers.
These interfaces and classes are required as part of the Java™ Platform, Standard Edition (Java SE), but there is no requirement to provide any tools implementing them.
...
There is no requirement for a compiler at runtime.
(здесь)
N>С Python, думаю, опятьже дело в некорректных тестах (см ниже).
Ну да, все тесты у нас у всех некорректные .
N>>>Гораздо более интересные языки чем C# держит и ничего (Scala) АХ>>Ну, во-первых Scala бывает весьма ощутимо тормозит: АХ>>[Benchmark] Встроенный while vs макросы vs замыкания на Scala
N>Бенчмарк, как всегда, некорректен Не видел еще ни одного бенчмарка, который адепты C# написали бы корректно для Java или ее производных.
Ну давай изложи свое видение как должно быть корректно. Не супертюнинг конкретной VM под конкретный бенчмарк (хотя все равно подозреваю что быстрее .NET не будет), а общие опции.
N> В данном случае, не учтено время, которое тратит компилятор byte code -> native code. Вернее, оно не вынесено за рамки измерений.
Как это не вынесено? Я вынес. Там замеряется время внутри. Более того, функция также вызывается и до измерения.
N>Как минимум, нужно вставлять -Xcomp -Xbatch и результаты будут в разы лучше.
1) Это нестандартные флаги и не во всех VM они есть:
У меня стоит HotSpot:
D:\>java1 -version
java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03)
Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode)
и JRockit
D:\>java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
BEA JRockit(R) (build R26.4.0-63-63688-1.5.0_06-20060626-2259-win-ia32, )
у HotSpot есть только -Xbatch
D:\>java1 -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
У JRockit таких опций не вижу
D:\>java -X
-Xbootclasspath:<directories and zip/jar files separated by :>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by :>
prepend in front of bootstrap class path
-Xgcprio:[throughput|pausetime|deterministic]
sets prio for the gc-system
throughput optimizes the gc-behavior to achieve optimal
throughput (initially starts off with
single-spaced parallel GC mode but may switch
to other GC modes dynamically during runtime)
pausetime optimizes the gc-behavior to achieve minimal
pause times (initially starts off with
single-spaced concurrent GC mode but may switch
to other GC modes dynamically during runtime)
deterministic optimizes the gc-behavior to ensure extremely
short pause times and limit the total number of
those pauses within a prescribed window (this
feature requires a valid license)
-Xgc:[singlecon|gencon|parallel]
used to set a static garbage collector
will override the -Xgcprio option
singlecon use the single-spaced concurrent garbage
collector algorithm (default in client mode)
gencon use the generational concurrent
garbage collector algorithm
parallel use the single-spaced parallel
garbage collector algorithm
(default in server mode)
-Xms<size>[g|G|m|M|k|K]
sets the initial Java heap size (ms)
server mode: the default value is 25% of the amount
of free physical memory in the system
up to 64 MB with a minimum of 8 MB (default)
client mode: the default value is 25% of the amount
of free physical memory in the system
up to 16 MB with a minimum of 8 MB
-Xmx<size>[g|G|m|M|k|K]
sets the maximum Java heap size (mx)
server mode: the default value is the smallest of 75% of
physical memory and 1536 MB (default)
client mode: the default value is the smallest of 75% of
physical memory and 64 MB
-Xns<size>[g|G|m|M|k|K]
sets the initial Java nursery size for generational collectors
server mode: the default value is 10 MB per (default)
client mode: the default value is 2 MB
-Xss<size>[g|G|m|M|k|K]
set initial stack size
-Xpausetarget=<optimal_pause_time>[ms|s]
JRockit will optimize the pause time to the given target,
uses -Xgcprio:pausetime
ms pause time specified in milliseconds (default)
s pause time specified in seconds
-Xnoclassgc
disable class garbage collection
-Xgcpause
print pause times caused by the garbage collector
-Xgcreport
write extensive memory report at end of run
-Xdebug
enables debugging support in the VM
-Xrun<library>
loads and runs a library
-Xjvmpi:[<argument1>=<value1>[,<argumentN>=<valueN>]]
enable/disable groups of jvmpi events when running jvmpi
entryexit (default on)
allocs (default on)
monitors (default on)
-Xmanagement
enable the management server needed by the
JRockit Console
-Xnoopt
do not optimize code
-Xstrictfp
always use strict floating point calculations
-Xverify
do full bytecode verification
-Xnohup or -Xrs
JRockit will not process CTRL_LOGOFF_EVENT or SIGHUP events
-Xverbose[:memory|load|jni|cpuinfo|codegen|opt]
enable verbose output
-Xverboselog:<file>
log verbose output to a file
-Xverbosetimestamp
adds a timestamp to the verbose printout
2) попробовал HotSpot с -Xcomp -Xbatch (-Xcomp оказывается работает, правда об этом в опциях ни слова ).
Небольшое ускорение в обычном цикле (все равно ~ в 8 раз медленее MS.NET):
Simple do-while: 1352
Repeat until: 4006
АХ>>
АХ>>We haven't yet gone very far into evaluating those thingies
АХ>>(nemerle is dotnet and dotnet offers very far reaching possibilities to
АХ>>emit code at runtime, Java is a bit clumsy and middle-ages in that respect)
N>Ну, это уже не актуально с появлением compiler API.
см. выше
АХ>>Нет, MS учел уроки Java и создал более технологически совершенный .NET. Я не фанат MS и мне больше нравится то что Java под GPL, но тем не менее это так. И практически во всех тестах MS.NET быстрее Java (здесь писал в ФП).
N>Все эти т.н. "тесты" либо не учитывают то, что в начале работы происходит компиляция в native code, либо запускаются на client JVM, либо содержат другие грубые ошибки.
В моих тестах замер делается внутри (т.е. время на старт не учитывается), запускал на разных VM и -server и -client (об этом тоже писал), причем не всегда -server лучше. То что HotSpot иногда вылетает в интерпретацию — так это его реальные условия работы: все честно. Про другие грубые ошибки прошу поподробнее.
N> Если все аккуратно и правильно сделать, то разницу можно увидеть только в конкретных местах, где нечто реализовано существенно по разному.
N>Например, примитивные типы данных работают быстрее в Java т.к. это не value типы, а отдельная сущность.
Это как это они быстрее value типов ? Примеры давай.
N> А в некоторых случаях микробенчмарк можно завязать на value типы и он будет быстрее в .NET.
N>Или вот в последнем JDK сделали lock elimination/coalesce с помощью escape analysis. Теперь легко можно будет сделать бенчмарк в котором на синхронизации Java будет на порядок быстрее.
ссылка, пример?
N>Из того, что я еще могу вспомнить — в Java гораздо более продвинутая memory model,
А чем это она так особо продвинутая?
N> которая позволяет компилятору делать очень много оптимизаций и собственно hotspot в то время как основную компиляцию в bytecode .NET делает один раз.
HotSpot и сам ресурсы отъедает, так что на практике один хрен, а подчас даже хуже (может улететь в интерпретацию).
Но в принципе да, подход неплохой.
N>Короче, еще раз, по большей части песни о немеряном технологическом приемуществе .NET VM над JVM это чистый маркетинг.
Да оно не немеряное, но некоторое есть.
N> Корректный микробенчмарк сделать и запустить на JVM не так просто, но, она для этого и не предназначена.
Во-во. Почему-то под .NET и без танцев с бубнами все несколько быстрее.
P.S. Я не адепт C# и вообще на нем писал довольно мало.
Здравствуйте, Alexandro, Вы писали:
GNU>> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу. A>большие методы прекрасно разделяются компилятором на мелкие.
Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.
A> делегаты = интерфейс + анонимный класс. где тут потеря производительности?
Там и потеря, что в дотнете делегат содержит указатель на функцию. Прежде чем вещать с умным видом — измерил бы сам. Я — измерял разницу в производительности, знаю, о чем говорю.
A> INTPTN — каюсь, не знаю что это. и гугл не знает. Нативные вызовы?
Указатель на функцию.
A> jni. Другая архитектура и переносимо. Так что действительно лучше вовсе помолчать.
*ROTFL*
A>мда, а мужики то не знают, что нельзя и реализуют здесь. Хотя секция ML пуста.
Учился б ты читать, однако. Мне нужна эффективная реализация, а не тот позорный бред.
GNU>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно.
Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
Здравствуйте, n0name2, Вы писали:
GNU>> В JVM нет хвостовой рекурсии. В .NET есть. В JVM нет структур, явно выделяемых на стеке — в .NET есть. В JVM есть лимит на размер методов — явно следующий из привязки к модели разработки на убогом язычке Java — в .NET такого предела нет.
N>И это ты называешь технологическим приемуществом?
yep
N> Собственно, кроме хвостовой рекурсии ни одного более менее серьезного пункта.
Large methods — kinda showstopper. Think about an EFFICIENT FSM implementation, pal.
N> Хотя, это тоже вполне решаемый вопрос, если бы кому-то она была бы всерьез нужна — давно бы сделали.
Фигнаны. Изначально заложенная ошибка проектирования.
N>Размер методов — стыдно вообще об этом упомянать, обходится элементарно,
Muahahahahaha! Элементарно? Жду примера элементарно реализованного ЭФФЕКТИВНОГО интерпретатора байткодов для относительно сложной VM.
N> Причем, это будет прозрачно для программиста, не нужно будет использовать разные сущности для того, чтобы добится аллокации на стеке.
А оно мне надо? Мне нужна гибкость и контроль.
N>Если так подходить, то, у JVM есть свои технологические приемущества, актуальные для императивных языков — в Java есть примитивные типы данных, более эффективные чем структуры,
?!?
:-O
N> в Java есть escape analysis, в Java есть hotspot машина, в Java есть быстрый biased locking и т.д.
Здравствуйте, Alexandro, Вы писали:
GNU>> Смешное ты существо. Я под JVM около десятка разнообразных компиляторов написал. Для Java я писал source->source трансляторы и системы статического анализа кода. Я, в отличии от тебя, малограмотного, очень даже хорошо знаю, о чём говорю.
A>Я не опущусь до оскорбления таких ничтожеств как ты. Закончил.
Гы, сына, ЛОЛ! Маленький ламерок обиделся, как это трогательно!
А какой функционал нужен то? Не хватает компилятора... Ну, юзай тогда другие средства генерации байт кода. Их полно (библиотек), BCEL, ASM, Javassist. Напиши кусок кода, и я тебе скажу как его проще всего сдалать на Java.
АХ>These interfaces and classes are required as part of the Java™ Platform, Standard Edition (Java SE), but there is no requirement to provide any tools implementing them. АХ>There is no requirement for a compiler at runtime. АХ>[/q]
Реально compiler API работает. Лично мне этого достаточно.
АХ>Как это не вынесено? Я вынес. Там замеряется время внутри. Более того, функция также вызывается и до измерения.
Для того, чтобы было более-менее корректно, в общем случае, нужно сначала прогнать в цикле исполнение функции более N раз, где N это CompilerThreshold, она разная по умолчанию для разных типов JVM, можно ее задавать. А лучше — прогнать еще больше раз т.к. hotspot может несколько раз перекомпилировать метод на лету чтобы улучшить производительность.
Т.е. нужно не сначала погонять код, потом начать отсчет замера. Примерно так
void test() {
}
void main() {
for (int i = 0;i < 100 * 1000;i++) test();
long start = System.nanoTime();
for (int i = 0;i < 100 * 1000;i++) test();
long elapsed = System.nanoTime() - start;
}
Плюс -server нужно использовать практически всегда, также есть много полезных опций в т.ч. -XX:+AgressiveOpts -XX:+BiasedLocking и много других. Каждая из которых нужна для своих задач — для ускорения locking, для оптимизаций работы с большой кучей и т.д. и т.п.
Еще посмотри здесь.
N>>Как минимум, нужно вставлять -Xcomp -Xbatch и результаты будут в разы лучше. АХ>1) Это нестандартные флаги и не во всех VM они есть:
Это неважно. Разные JVM действительно имеют свои особенности, но это не значит что их не надо использовать. Кстати, поставь Java6. И еще Excelsior JET для полноты коллекции.
АХ> -Xms<size> set initial Java heap size АХ> -Xmx<size> set maximum Java heap size АХ> -Xss<size> set java thread stack size АХ> -Xprof output cpu profiling data АХ> -Xfuture enable strictest checks, anticipating future default АХ> -Xrs reduce use of OS signals by Java/VM (see documentation)
Это примерно 10% от всех доступных опций. Большинство из них описано в детальной документации. Их очень много. здесь но это не все... Более правильные доки есть для каждой конкретной версии JVM.
АХ>2) попробовал HotSpot с -Xcomp -Xbatch (-Xcomp оказывается работает, правда об этом в опциях ни слова ). АХ> Небольшое ускорение в обычном цикле (все равно ~ в 8 раз медленее MS.NET): АХ>
АХ>Simple do-while: 1352
АХ>Repeat until: 4006
У меня на Java6 client примерно 700ms/2000ms. Но, еще раз повторюсь — в данном конкретном случае это баг server JVM и нежелание Scala использовать встроенный boolean.
АХ>В моих тестах замер делается внутри (т.е. время на старт не учитывается), запускал на разных VM и -server и -client (об этом тоже писал), причем не всегда -server лучше. То что HotSpot иногда вылетает в интерпретацию — так это его реальные условия работы: все честно. Про другие грубые ошибки прошу поподробнее.
Нет, просто замера недостаточно, нужно еще отбрасывать то время, которое тратит компилятор на создание native code. См выше. Он это делает ПАРАЛЛЕЛЬНО с исполнением кода в интерпретируемом режиме. HotSpot работает как интерпретатор только для тех участков кода, которые оно считает недостойными компиляции (оч редко вызываемыми) и для которых производителность совершенно неважна. Так что сравнивать скорость интерпретации и скомпилированного кода это бредовая затея.
Основные ключи, которые нужно указывать обязательно для микробенчмарков (Java6, HotSpot): -server -Xmx512m -Xms512m -XX:+AggressiveOpts -XX:+DoEscapeAnalysis -XX:+UseBiasedLocking
-Xcomp -Xbatch нужы только для того, чтобы компиляция прошла сразу а не параллельно с исполнением кода. Но, по хорошему так делать не нужно т.к. вначале у HotSpot нет информации о том, как себя код ведет в runtime. Лучше использовать техники, описанные выше.
Если это тест на создание объектов и/или скорость GC то тут тоже есть тонкости, нужно по максимуму использовать Thread Local Object Allocation, ключи соот-ие сходу не помню. Ну, и опции по использованию throughput parallell GC (если нужен throughput) или concurrent low pause GC (если нужны короткие паузы).
Для JRockit опции совершенно другие, если нужно будет — напишу о них.
N>>Например, примитивные типы данных работают быстрее в Java т.к. это не value типы, а отдельная сущность. АХ>Это как это они быстрее value типов ? Примеры давай.
Простейшие задачи — работа с массивом double/long. Например, сортировка пузырьком. Есть у .NET C# компилятор, который можно скачать без Visual Studio (command line only)? Если да, то могу попробовать написать такого рода тест.
N>>Или вот в последнем JDK сделали lock elimination/coalesce с помощью escape analysis. Теперь легко можно будет сделать бенчмарк в котором на синхронизации Java будет на порядок быстрее. АХ>ссылка, пример?
Пример простейший
public class Test30 {
public int i = 0;
public synchronized void test() { i++; }
public static void x(String[] args) {
long start = System.nanoTime();
Test30 t = new Test30();
for (int i = 0; i < 1000 * 1000; i++) t.test();
System.out.println("Elapsed: " + (double)(System.nanoTime() - start) / 1.0e6);
}
public static void main(String[] args) {
x(args); x(args); x(args); x(args);
}
}
Работает с тойже скоростью что и без synchronized если JVM определит что другие потоки не сонхронизуются на томже мониторе. Еще умеет synchronized блоки объеденять.
здесь. К сожалению, литература по этому вопросу в основном относится к разного рода research, про конкретную имплементацию мало пишут.
N>>Из того, что я еще могу вспомнить — в Java гораздо более продвинутая memory model, АХ>А чем это она так особо продвинутая?
Тем, что не гарантирует видимость переменных, записыных в память одним потоком другому потоку. Для этого обязательно нужно использовать synchronize или volatile переменные. Это позволяет компилятору и вообще runtime делать много оптимизаций. Плюс это позволяет нормально работать на nccNUMA архитектурах (вообще говоря, за ними будующее).
N>> которая позволяет компилятору делать очень много оптимизаций и собственно hotspot в то время как основную компиляцию в bytecode .NET делает один раз. АХ>HotSpot и сам ресурсы отъедает, так что на практике один хрен, а подчас даже хуже (может улететь в интерпретацию). АХ>Но в принципе да, подход неплохой.
Конечно, интерпретация гораздо медленнее. Но, в реальной жизне а не в микробенчмарках это незаметно т.к. интерпретируются только редко используемые куски кода. А подход очень правильный т.к. компиляция итеративна и код постоянно улучшается в зависимости от метрик. И HotSpot когда все скомпилировалось есть уже мало ресурсов.
N>>Короче, еще раз, по большей части песни о немеряном технологическом приемуществе .NET VM над JVM это чистый маркетинг. АХ>Да оно не немеряное, но некоторое есть.
Ну у JVM тоже есть свои.
N>> Корректный микробенчмарк сделать и запустить на JVM не так просто, но, она для этого и не предназначена. АХ>Во-во. Почему-то под .NET и без танцев с бубнами все несколько быстрее.
Ну так JVM не для микробенчмарков создавалась а для выполнения реальных приложений.
Здравствуйте, GNUzaurus, Вы писали:
GNU> Large methods — kinda showstopper. Think about an EFFICIENT FSM implementation, pal.
Если не нужно чтобы метод был виртуальным (нет его переопределений), Java его не будет в native code делать таковым. Тебе в методе стек большой нужен? Его можно заменить переменными класса?
N>> Хотя, это тоже вполне решаемый вопрос, если бы кому-то она была бы всерьез нужна — давно бы сделали.
GNU> Фигнаны. Изначально заложенная ошибка проектирования.
Размеры метода — всего лишь ограничение формата классов. Просто сделать новую спецификацию и все. С tail recursion — там все в security упирыется, но, это не проблема если весь код в одном security domain находится (99.99% случаев). Ниче там фундаментального нет совершенно.
N>> Причем, это будет прозрачно для программиста, не нужно будет использовать разные сущности для того, чтобы добится аллокации на стеке. GNU> А оно мне надо? Мне нужна гибкость и контроль.
Конечно надо. Один и тотже класс будет создаватся или в хипе или на стеке в зависимости от того, как его использовать. Сильно упрощает все.
Здравствуйте, n0name2, Вы писали:
GNU>> Large methods — kinda showstopper. Think about an EFFICIENT FSM implementation, pal.
N>Если не нужно чтобы метод был виртуальным (нет его переопределений), Java его не будет в native code делать таковым. Тебе в методе стек большой нужен? Его можно заменить переменными класса?
Мне нужны переходы внутри метода. Если метод разбить на несколько, то переходы станут вызовами, и тогда начнет расти стек.
GNU>> Фигнаны. Изначально заложенная ошибка проектирования.
N>Размеры метода — всего лишь ограничение формата классов. Просто сделать новую спецификацию и все.
Я пробовал этот вопрос изучить. Облом там выходит — не получится обратной совместимости.
N> С tail recursion — там все в security упирыется, но, это не проблема если весь код в одном security domain находится (99.99% случаев). Ниче там фундаментального нет совершенно.
Естъ. Стековые операции вроде swap, которых в дотнете нет вовсе.
GNU>> А оно мне надо? Мне нужна гибкость и контроль.
N>Конечно надо. Один и тотже класс будет создаватся или в хипе или на стеке в зависимости от того, как его использовать. Сильно упрощает все.
Не упрощает ни фига. Производительность страдает — во время компиляции я лучше знаю, кому в стек, а кому в кучу. Hotspot знает меньше, он глупее.
Здравствуйте, GNUzaurus, Вы писали:
GNU> Мне нужны переходы внутри метода. Если метод разбить на несколько, то переходы станут вызовами, и тогда начнет расти стек.
А если FSM разделить на две половины (или неважно сколько частей), и половину переходов делать в одном методе, половину в другом, то стек будет расти не так сильно. Да и выходить можно из фрэйма назад чтобы стек не разростался...
Но, вообще, все-таки в реальных задачах гораздо больше времени тратится на работу в рамках некоторого одного состояния. Так что накладные расходы FSM, по крайней мере для тех задач с которыми я встречался были совершенно неважны.
Хотя, если вся программа это большая FSM, то да, тут косяк.
N>>Размеры метода — всего лишь ограничение формата классов. Просто сделать новую спецификацию и все. GNU> Я пробовал этот вопрос изучить. Облом там выходит — не получится обратной совместимости.
А она и не нужна. Совместимости по версиям class files сверху вних нет и сейчас, classes от Java5 на Java1.4.x не запустить. Только снизу вверх.
N>> С tail recursion — там все в security упирыется, но, это не проблема если весь код в одном security domain находится (99.99% случаев). Ниче там фундаментального нет совершенно. GNU> Естъ. Стековые операции вроде swap, которых в дотнете нет вовсе.
Может быть, но, все-таки раз в IBM JVM это сделали, то и в Sun HotSpot запихают при желании.
N>>Конечно надо. Один и тотже класс будет создаватся или в хипе или на стеке в зависимости от того, как его использовать. Сильно упрощает все. GNU> Не упрощает ни фига. Производительность страдает — во время компиляции я лучше знаю, кому в стек, а кому в кучу. Hotspot знает меньше, он глупее.
Неа, HotSpot знает больше. Вот ты сделал библиотеку, допустим, там есть класс Line { int x0, y0, x1, y1; void draw(); }. И ты не знаешь как его будут юзать в тех приложениях, которые твою библиотеку пользуют. Либо они будут создавать Line и он будеь not escaped (т.е. в рамках фрейма конкретного метода и заинлайненых в него методов), либо его будут таскать туда-сюда.
А HotSpot это знает и в одном случае его на стеке положит, в другом в куче.
Здравствуйте, n0name2, Вы писали:
N>А если FSM разделить на две половины (или неважно сколько частей), и половину переходов делать в одном методе, половину в другом, то стек будет расти не так сильно. Да и выходить можно из фрэйма назад чтобы стек не разростался...
Плохая затычка. Общего и универсального решения не получится. И вообще, стек расти не должен — мы ведь не знаем, что за дрянь нам на вход подсунут, ситуация с стацк оверфлощ будет при таком подходе возможной всегда.
N>Но, вообще, все-таки в реальных задачах гораздо больше времени тратится на работу в рамках некоторого одного состояния.
Парсер. Любой. Узкое место — переходы.
N>Так что накладные расходы FSM, по крайней мере для тех задач с которыми я встречался были совершенно неважны.
Мне б такие задачи...
N>Хотя, если вся программа это большая FSM, то да, тут косяк.
Очень частый случай.
N>А она и не нужна. Совместимости по версиям class files сверху вних нет и сейчас, classes от Java5 на Java1.4.x не запустить. Только снизу вверх.
Снизу вверх тоже ломается.
N>Может быть, но, все-таки раз в IBM JVM это сделали, то и в Sun HotSpot запихают при желании.
Сделали — но без гарантии. То есть, пользы от нее — никакой.
GNU>> Не упрощает ни фига. Производительность страдает — во время компиляции я лучше знаю, кому в стек, а кому в кучу. Hotspot знает меньше, он глупее.
N>Неа, HotSpot знает больше.
Не знает. У меня инфа о статических типах была — а у хотспота уже нет ее. Да и времени на оптимизацию у меня гораздо больше.
N> Вот ты сделал библиотеку, допустим, там есть класс Line { int x0, y0, x1, y1; void draw(); }. И ты не знаешь как его будут юзать в тех приложениях, которые твою библиотеку пользуют. Либо они будут создавать Line и он будеь not escaped (т.е. в рамках фрейма конкретного метода и заинлайненых в него методов), либо его будут таскать туда-сюда.
Я сделаю полиморфную библиотеку. И код от нее инлайниться будет, вообще без вызовов обойдемся. Но JVM мне руки выкручивает, я так только в .НЕТ могу.
N>А HotSpot это знает и в одном случае его на стеке положит, в другом в куче.
Но вызовы методов библиотеки всегда будут по ссылке. Дорого.
Здравствуйте, GNUzaurus, Вы писали:
N>>Но, вообще, все-таки в реальных задачах гораздо больше времени тратится на работу в рамках некоторого одного состояния. GNU> Парсер. Любой. Узкое место — переходы.
Незнаю, javac довольно шустро работает. С JavaCC особенно не натыкался на ограничения. Хотя, все может быть, если шибко сложный парсер нужен. Я только с простыми языками вроде тойже Java работал, ну и для HTML там парсер...
N>>Так что накладные расходы FSM, по крайней мере для тех задач с которыми я встречался были совершенно неважны. GNU> Мне б такие задачи...
Собственно, автоматизация бизнеса, веб приложения и т.д. 90% применений что Java что C# из этой области, ИМХО.
N>>А она и не нужна. Совместимости по версиям class files сверху вних нет и сейчас, classes от Java5 на Java1.4.x не запустить. Только снизу вверх. GNU>Снизу вверх тоже ломается.
Почему? Что мешает на лету расширять размеры таблиц в классах до 32х битных или транслировать байт код в новую версию?
N>>Может быть, но, все-таки раз в IBM JVM это сделали, то и в Sun HotSpot запихают при желании. GNU>Сделали — но без гарантии. То есть, пользы от нее — никакой.
Побробнее, если не сложно.
GNU> Не знает. У меня инфа о статических типах была — а у хотспота уже нет ее. Да и времени на оптимизацию у меня гораздо больше.
Времени у HotSpot предостаточно, несколько раз перекомпилирует тело метода, он может часами статистику собирать. И не для всего нужны оптимизации серьезные, собственно, спотов в программе не так уж и много.
А то, что было до type erasure ну... наверное интересно, но, не особенно. Все равно runtime type checks нужны будут в любом случае.
GNU> Я сделаю полиморфную библиотеку. И код от нее инлайниться будет, вообще без вызовов обойдемся. Но JVM мне руки выкручивает, я так только в .НЕТ могу.
А как ты полиморфную библиотеку на value types сделаешь если Unlike reference types, it is not possible to derive a new type from a value type?
GNU> Но вызовы методов библиотеки всегда будут по ссылке. Дорого.
HotSpot определяет если виртуальный метод нам сейчас не нужен, то заинлайнит, невопрос. Это .NET руки выкручивает — юзай кастрированные классы если хочешь чтобы они были в стеке.
Здравствуйте, n0name2, Вы писали:
GNU>> Парсер. Любой. Узкое место — переходы.
N>Незнаю, javac довольно шустро работает. С JavaCC особенно не натыкался на ограничения.
Binary parsing — более тяжкий случай. В javac все равно не в парсере bottleneck.
GNU>> Мне б такие задачи...
N>Собственно, автоматизация бизнеса, веб приложения и т.д. 90% применений что Java что C# из этой области, ИМХО.
Расплывчато. Даже в этих категориях порой встречается rocket science.
N>Почему? Что мешает на лету расширять размеры таблиц в классах до 32х битных или транслировать байт код в новую версию?
А вот про трансляцию я пока не думал. Буду думать заново.
GNU>>Сделали — но без гарантии. То есть, пользы от нее — никакой.
N>Побробнее, если не сложно.
Там не каждый хвостовой вызов корректно определяется и не каждый оптимизируется. То есть, рассчитывать на хвостатость рекурсии нельзя — могут и обломать.
GNU>> Не знает. У меня инфа о статических типах была — а у хотспота уже нет ее. Да и времени на оптимизацию у меня гораздо больше.
N>Времени у HotSpot предостаточно, несколько раз перекомпилирует тело метода, он может часами статистику собирать.
Мне не надо часами собирать. Мне надо сразу быстрый отклик поиметь — пусть даже это ни фига не хотспот и в этом коде и процента времени не наберется — мне не только интегральная производительность требуется, но и локальная.
N>А то, что было до type erasure ну... наверное интересно, но, не особенно. Все равно runtime type checks нужны будут в любом случае.
Не, runtime — не нужны. Все было во время компиляции, а после только туплы с тагами остались.
GNU>> Я сделаю полиморфную библиотеку. И код от нее инлайниться будет, вообще без вызовов обойдемся. Но JVM мне руки выкручивает, я так только в .НЕТ могу.
N>А как ты полиморфную библиотеку на value types сделаешь если Unlike reference types, it is not possible to derive a new type from a value type?
А мне вообще система типов в .NET и в JVM по сараю, мне все эти классы-шмассы только мешают. У меня свои системы типов.
GNU>> Но вызовы методов библиотеки всегда будут по ссылке. Дорого.
N>HotSpot определяет если виртуальный метод нам сейчас не нужен, то заинлайнит, невопрос.
Он это делает дюже погано.
N>Это .NET руки выкручивает — юзай кастрированные классы если хочешь чтобы они были в стеке.
Мне классы вообще не нужны, и я рад возможности пользовать более внятные структуры.
Здравствуйте, GNUzaurus, Вы писали:
N>>Собственно, автоматизация бизнеса, веб приложения и т.д. 90% применений что Java что C# из этой области, ИМХО. GNU> Расплывчато. Даже в этих категориях порой встречается rocket science.
Бывает, но, совсем чуть-чуть и в принципе в рамках ограничений JVM вполне решается.
GNU> Там не каждый хвостовой вызов корректно определяется и не каждый оптимизируется. То есть, рассчитывать на хвостатость рекурсии нельзя — могут и обломать.
Собственно, генерить код надо по одинаковому паттерну да и все. Все-таки, хвостовая рекурсия штука несложная.
Кстати, читал что этот explicit tail rec instruction в .NET типа все равно довольно медленный т.к. security domains проверяет каждый раз.
И вообще, раз уж собственный компилятор, почему бы сразу в цикл ее не разворачивать, у меня IDE и то это предлагает сделать автоматически.
GNU> Мне не надо часами собирать. Мне надо сразу быстрый отклик поиметь — пусть даже это ни фига не хотспот и в этом коде и процента времени не наберется — мне не только интегральная производительность требуется, но и локальная.
Невопрос — скомпилируй в native executable с помощью excelsior jet. Там, кстати, stack allocation уже сделали здесь. Классический компилятор, type erasure его особенно не косается. Скорее всего, и tail rec оптимизирована.
GNU> А мне вообще система типов в .NET и в JVM по сараю, мне все эти классы-шмассы только мешают. У меня свои системы типов. GNU>Мне классы вообще не нужны, и я рад возможности пользовать более внятные структуры.
Смысл тогда вообще .NET/JVM юзать — интероперабельности с библиотеками не добится, а в этом их основная ценность... Разве что ради имплементации GC...
Здравствуйте, n0name2, Вы писали:
GNU>> Расплывчато. Даже в этих категориях порой встречается rocket science.
N>Бывает, но, совсем чуть-чуть и в принципе в рамках ограничений JVM вполне решается.
Увы, если работать эффективно, не тратить время на легкоавтоматизируемую рутину (ту, которую в отсталых конторах разгребают руками посредственных "кодеров"), то именно такие задачи и становятся главным тормозом. И плохо, когда ограничения среды, рассчитаной на посредственных программистов, мешают эффективно работать хорошим и грамотным товарищам.
GNU>> Там не каждый хвостовой вызов корректно определяется и не каждый оптимизируется. То есть, рассчитывать на хвостатость рекурсии нельзя — могут и обломать.
N>Собственно, генерить код надо по одинаковому паттерну да и все. Все-таки, хвостовая рекурсия штука несложная.
Я такого стабильно срабатывающего шаблона пока не нашел.
N>Кстати, читал что этот explicit tail rec instruction в .NET типа все равно довольно медленный т.к. security domains проверяет каждый раз.
Конкретно — в 3-4 раза медленнее локального перехода.
N>И вообще, раз уж собственный компилятор, почему бы сразу в цикл ее не разворачивать, у меня IDE и то это предлагает сделать автоматически.
Это далеко не всегда возможно. Особенно если вызываемую аункцую или замыкание мы получаем как аргумент текущей функции.
N>Невопрос — скомпилируй в native executable
Когда есть возможность использовать нейтив, я и компиляю сразу в нейтив, без посредников. Мне тогда даром все эти жабы с дотнетами не нужны. Увы, это не всегда возможно — тот же J2ME, хотя бы.
GNU>>Мне классы вообще не нужны, и я рад возможности пользовать более внятные структуры.
N>Смысл тогда вообще .NET/JVM юзать — интероперабельности с библиотеками не добится,
Добиваюсь. Через дополнительную прослойку.
N> а в этом их основная ценность... Разве что ради имплементации GC...
К сожалению, выбор платформы часто строго ограничен.
Здравствуйте, GNUzaurus, Вы писали:
N>>Кстати, читал что этот explicit tail rec instruction в .NET типа все равно довольно медленный т.к. security domains проверяет каждый раз. GNU> Конкретно — в 3-4 раза медленнее локального перехода.
Тогда действительно видимо приходится здоровенную стэйт машину делать... С таким оверхедом, в принципе, можно попробовать и в Java что-то придумать вроде trampalins.
N>>Невопрос — скомпилируй в native executable GNU> Когда есть возможность использовать нейтив, я и компиляю сразу в нейтив, без посредников. Мне тогда даром все эти жабы с дотнетами не нужны. Увы, это не всегда возможно — тот же J2ME, хотя бы.
Ну так на .NET ведь ты exe файл получаешь на выходе. Тут тоже самое. Для J2ME конечно не катит, без вопросов.
Здравствуйте, GNUzaurus, Вы писали:
GNU>Здравствуйте, Alexandro, Вы писали:
GNU>>> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу. A>>большие методы прекрасно разделяются компилятором на мелкие.
GNU>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.
А мне нужно чтобы все работало сразу и без багов . Если бы вы были немного грамотнее и смотрели на мир не так однобоко, то поняли бы, что возможностей для маневра в любом случае хватает.
A>> делегаты = интерфейс + анонимный класс. где тут потеря производительности?
GNU> Там и потеря, что в дотнете делегат содержит указатель на функцию. Прежде чем вещать с умным видом — измерил бы сам. Я — измерял разницу в производительности, знаю, о чем говорю.
И как же вы меряли, интересно?
Специально ради тебя написал небольшой тест:
// C#using System;
using System.Diagnostics;
public delegate void fun();
public class Test {
public static void doF(){
}
public static void Main(String[] args) {
fun f = doF;
Stopwatch sw = new Stopwatch();
sw.Start();
for(int j = 0; j < 10000; ++j)
for(int i = 0; i < 10000; ++i)
f();
sw.Stop();
Console.WriteLine("time " + sw.ElapsedMilliseconds);
}
}
// javapublic class Test {
public interface Fn {
void doF();
}
public static void main(String[] args) {
Fn f = new Fn() {
int val = 0;
public void doF(){
}
};
long time = System.currentTimeMillis();
for(int j = 0; j < 10000; ++j)
for(int i = 0; i < 10000; ++i)
f.doF();
System.out.println("time " + (System.currentTimeMillis() - time));
}
}
в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.
A>> INTPTN — каюсь, не знаю что это. и гугл не знает. GNU> Указатель на функцию.
Поздравляю с изобретением нового термина.
A>>мда, а мужики то не знают, что нельзя и реализуют здесь. Хотя секция ML пуста. GNU>Учился б ты читать, однако. Мне нужна эффективная реализация, а не тот позорный бред.
тогда пиши свою.
GNU>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно. GNU> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
hotspot. хвостовые вызовы будут работать там, где это необходимо.
ЗЫ. бегло проглядел твой профиль. Судя по стилю твоего общения (и не со мной тоже) — ты только что и можешь, что выплескивать свои эмоции на форуме. Логические доводы в твоих рассуждениях отсутсвуют как класс. Пытаясь показаться значительнее, ты кажешься только смешнее. Это мое ИМХО. Общаться с тобой на форуме более не вижу смысла. Если хочешь развеять свои заблуждения — прошу в аську.
ЗЗЫ. для модераторов: прошу прощения за переход на личности. По другому с такими типами я общаться не умею.
Жабист жабисту друк, но истина дороже...
A>Специально ради тебя написал небольшой тест: A>скомпилировал, запустил. A>результаты: A>c# — 650ms A>java — 141ms (-server), 297ms(-client)
Тест некорректен т.к. в данном случае был просто inline кода. Для того, чтобы он был несколько более правильным, нужно сделать следующее:
1. Нужно несколько реализаций Fun, и они должны использоватся. В этом случае нужны будут виртуальные вызовы. Т.е. тест нужно переписать чтобы было несколько "делегатов" и они все участвовали в тесте.
2. Тело метода вообще пустое. Скорее всего, компилятор его выкинул. Нужно что-то в нем делать более-менее полезное.
3. В java версии нужно делать warmup (см мои посты выше), иначе ты работаешь на интерпретируемом коде некоторое время.
Но, получившийся код все равно не будет неэквивалентен т.к. делегаты имеют доступ к фрейму функции, которая их вызывает, а анонимные методы — нет (только к константам).
Вообще, написать корректный микробенчмарк это очень непростое занятие.
A>в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.
Ты неправ, он по делу критикует JVM. Ограничение на 64к инструкций в методе, отсутствие явной поддержки хвостовой рекурсии и сложность в реализации continuations (хотя, в .NET это делают через хак с yield() который предназначен для другого) это действительно минусы с т.з. ФП языков под JVM. И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.
В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec. Чтобы все это исправить достаточно потратить некоторое кол-во ресурсов, выпустить новую спеку class file format и расширить список инструкций VM. Это вполне можно было бы сделать в одном из minor релизов, но, Sun занят другим. И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг.
В Java есть гораздо более значимые технологические приемущества в т.ч. новомодный escape analysis и thin locks. Но, самое главное это hot spotting, это очень правильный и грамотный подход. Эти вещи гораздо более сложные, интересные и ресурсоемкие чем те мелочи, которые мешают поклонникам ФП спокойно компилироваться в Java byte code.
GNU>>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно. GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО. A>hotspot. хвостовые вызовы будут работать там, где это необходимо.
Тут он прав. В Java нет выделенной инструкции для замены одного стекового фрейма на другой и соот-но программа, написанная на другом языке, но компилирующаяся в байт код не может явно указать что здесь нужна хвостовая рекурсия. По хорошему, такую инструкцию действительно надо ввести.
Здравствуйте, Alexandro, Вы писали:
GNU>>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.
A>А мне нужно чтобы все работало сразу и без багов .
У таких, как ты, этого не бывает. Чтоб без сразу багов — это как минимум строгая статическая типизация, с алгебраическими типами данных (да и type classes не повредят). А в ваших Жабках такого не водится, и компилять такие правильные языки под ваши ущербные JVM нереально.
A> Если бы вы были немного грамотнее и смотрели на мир не так однобоко, то поняли бы, что возможностей для маневра в любом случае хватает.
Ценой производительности, смешной ты человечек. За однобокость рантайма надо платить.
GNU>> Там и потеря, что в дотнете делегат содержит указатель на функцию. Прежде чем вещать с умным видом — измерил бы сам. Я — измерял разницу в производительности, знаю, о чем говорю. A>И как же вы меряли, интересно?
Корректно. А не так по ламерски, как ты. Соблаговоли в следующий раз смотреть на байткод, который из твоих тестов получается. Мы не компиляторы двух корявых язычков сравниваем, а виртуальные машины.
A>в очередной раз убедился, что весь ваш треп — просто газификация мелких природных водоемов, как сказали бы на ЛОРе.
А, с ЛОРа чувачок? Так бы сразу и сказал — я б на тебя тогда время не тратил.
A>>> INTPTN — каюсь, не знаю что это. и гугл не знает. GNU>> Указатель на функцию. A>Поздравляю с изобретением нового термина.
.net framework 1.1 его изобрел.
GNU>>Учился б ты читать, однако. Мне нужна эффективная реализация, а не тот позорный бред. A>тогда пиши свою.
Так в том и засада, что НЕЛьЗЯ написать! Вообще нельзя. Потому что JVM — говно.
GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО. A>hotspot. хвостовые вызовы будут работать там, где это необходимо.
Мсье, вы тормоз. Никакой хотспот не определит, где хвостовая рекурсия необходима, а где можно относительно безопасно поднасрать в стек.
A> Общаться с тобой на форуме более не вижу смысла. Если хочешь развеять свои заблуждения — прошу в аську.
Здравствуйте, n0name2, Вы писали:
N> это действительно минусы с т.з. ФП языков под JVM.
Попрошу заметить, что ФП я почти и не упоминал, упор делал на куда как более мейнстримные задачи — такие как большие ФСМ.
N> И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.
Мейнстрим — безмозгл. Он рулится толпой. Он сам не знает, чего он требует. Он и сборки мусора не требовал, пока ее ему не впарили. Были бы сантехники поответственнее — постарались бы впарить более серьезные вещи.
N>В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec.
Это не главный мой поинт. Даже если я, порвав себе все что только можно, вправлю мозги одной минорной форкнутой веточке Sun JVM, мой код все равно не будет работать ни у жаба-хостеров, ни на KVMах в миллионах мобилок. Так что, мои претензии к авторам ущербной и подлой JVM более чем обоснованы — у меня нет шансов исправить их глупость.
N> И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг.
Ничего в этом настолько важного нет...
N> Но, самое главное это hot spotting, это очень правильный и грамотный подход.
Который в большинстве случаев не годится. Чаще нужен разовый быстрый отклик — а потом метод и не вызовут больше ни разу. Особенно это в софт-риалтаймовых требованиях к UI проявляется. За это Жабку в ГУЙне и не любят.
Здравствуйте, GNUzaurus, Вы писали:
N>>В чем я не согласен с GNUzaurus, так это в том, что есть некие неустранимые design flaws в JVM spec. GNU> Это не главный мой поинт. Даже если я, порвав себе все что только можно, вправлю мозги одной минорной форкнутой веточке Sun JVM, мой код все равно не будет работать ни у жаба-хостеров, ни на KVMах в миллионах мобилок. Так что, мои претензии к авторам ущербной и подлой JVM более чем обоснованы — у меня нет шансов исправить их глупость.
Участвуй в процессе развития Java, запости патч на OpenJDK, создай JSR на изменение class file format. Спека Java7 еще не утверждена до конца, вполне возможно что туда это войдет.
Попроси коллег и друзей проголосовать за RFE на это изменение.
N>> И они правильно сделали что на это забили т.к. есть гораздо более важные и интересные вещи, такие как escape analysis, thin locks. Да даже банальный багфиксинг. GNU> Ничего в этом настолько важного нет...
Для твоих задач — наверное. Но, в типовом приложении порядка 20% CPU тратится на uncontended lock waits. Escape analysis + thin locks решают эту проблему. В качестве бонуса можно будет чаще делать API thread safe, если их будут использовать в одном потоке, компилятор уберет синхронизацию просто.
Кстати, в .NET, по крайней мере в 2.0 uncontended lock очень дорогой, раза в 4 дороже чем в Java.
На multicore эта проблема вообще стоит во весь рост. Твой язык, компилятор для которого ты делаешь, он вообще shared data предполагает? Или обмен сообщениями?
N>> Но, самое главное это hot spotting, это очень правильный и грамотный подход. GNU> Который в большинстве случаев не годится. Чаще нужен разовый быстрый отклик — а потом метод и не вызовут больше ни разу. Особенно это в софт-риалтаймовых требованиях к UI проявляется. За это Жабку в ГУЙне и не любят.
Лично меня вообще GUI не волнует совершенно. Для этого есть client VM, ориентированная как раз на такие случаи. Плюс юзай -Xcomp -Xbatch, это хинт JVM что мол — не нужно интерпретатор вообще юзать.
Зато технология позволяет уйти от хранения нативного кода внутири артифактов компиляции а самое главное позволяет делать очень забавные вещи.
Например, если HotSpot знает что есть только одна реализация интерфейса, то она не станет делать вызовы методов виртуальными. А если потом позже мы загрузим в VM новый код, который содержит вторую реализацию, то мы все перекомпилируем и у нас будут виртуальные вызовы. .NET так не может делать by design. Причем, это сложнее исправить чем размер метода или tail rec.
Здравствуйте, n0name2, Вы писали:
N>Ты неправ, он по делу критикует JVM. Ограничение на 64к инструкций в методе, отсутствие явной поддержки хвостовой рекурсии и сложность в реализации continuations (хотя, в .NET это делают через хак с yield() который предназначен для другого) это действительно минусы с т.з. ФП языков под JVM. И они не будут исправлены в HotSpot ближайшие годы т.к. для mainstream этого не требует.
yield() — это конструкция языка, к CLR он отношения не имеет и замечательно может быть сделан на JVM.
Здравствуйте, GNUzaurus, Вы писали:
GNU>>> Например, большие методы. Например, делегаты (потянет только с огромнейшей потерей производительности). Ну про INTPTN и нативные вызовы я и вовсе промолчу. A>>большие методы прекрасно разделяются компилятором на мелкие. GNU>Ха. Ха ха. Разделяются. Только на фиг мне это надо? Мне нужен один большой метод. С БЫСТРЫМИ переходами внутри. Если бы вы были немного грамотнее и знали бы, что такое FSM, то понимали бы, какую чушь вы несете.
Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем нет — лично писал такое. Просто переход на некоторые состояния делается в виде вызова метода.
GNU>>> Про наличие отсутствия хвостовых вызовов в убогонькой JVM так же и напоминать как-то неудобно, это очевидная и всем известная засада. A>>Каким образом должны хвостовые вызовы лежать в jvm? Очень интересно. GNU> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО.
Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают.
Ничего особого не мешает добавить tail-recursion в Java 7 — свободные байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию.
Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п.
Здравствуйте, Cyberax, Вы писали:
C>yield() — это конструкция языка, к CLR он отношения не имеет и замечательно может быть сделан на JVM.
Конечно можно, не вопрос. Но, для этого нужно ввести новую(ые) инструкцию(ии) в JVM byte code, которые будут оперировать стеком в рамках одного потока. В библиотеках полный аналог yield() не сделать (ну, разве что отдельный поток вводить).
C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете)
Серьезно чтоли? Нифига себе "технологически совершенная виртуальная машина"... Фактически нельзя без перезапуска VM обновить код приложения, например, новую версию webapp положить в IIS... Ужасъ, ф топку
Здравствуйте, Cyberax, Вы писали:
C>Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем нет — лично писал такое. Просто переход на некоторые состояния делается в виде вызова метода.
А в стек срать не стремно?
GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать ГАРАНТИРОВАННО. C>Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают.
Работают. Идеально. Проверял на ВСЕХ версиях. В 2.0 они еще и быстрее работать стали.
Или вы о том, что тупой компилятор тупого C# про них не знает? Так он мне и не интересен нисколько.
C>Ничего особого не мешает добавить tail-recursion в Java 7 — свободные байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию.
Как это аннотацию? Вызовов в методе может быть много, не все будут хвостовыми.
C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п.
Конечо дотнет не идеален. Он вообще — говно. Но по совокупности чуть меньшее говно, чем Жаба.
GNUzaurus wrote: > C>Э... А сделать НЕСКОЛЬКО методов? Для FSM здесь вообще никаких проблем > нет — лично писал такое. Просто переход на некоторые состояния делается > в виде вызова метода. > А в стек срать не стремно?
А какие проблемы?
Я делал примерно так:
...
static class FSMState
{
int state;
int payload;
...
}
public int process1(FSMState state)
{
while(true)
{
switch(state.state)
{
case 1:
state.state=doSomeAction();
case 2:
state.state=doSomeAction2();
default:
if (process2(state)==CONTINUE) continue;
if (process3(state)==CONTINUE) continue;
throw YouAreABadBoyException();
}
}
}
public int process2(FSMState state)
{
boolean first=true;
while(true)
{
switch(state.state)
{
case 3:
state.state=doSomeAction3();
case 4:
state.state=doSomeAction4();
default:
return first?CONTINUE:NOTCONSUMED;
}
first=false;
}
}
Ну и так далее. Естественно, тупой линейный поиск был оптимизирован. Но
общая идея должна быть понятна.
> GNU>> Префикс .tail в CLI. И хвостовые вызовы должны работать > ГАРАНТИРОВАННО. > C>Вот только... НЕ РАБОТАЮТ они в существующей .NET VM. А в Mono работают. > Работают. Идеально. Проверял на ВСЕХ версиях. В 2.0 они еще и быстрее > работать стали.
На .NET VM они не реализованы нормально — в Mono намного лучше сделано.
> C>Ничего особого не мешает добавить tail-recursion в Java 7 — свободные > байт-коды еще есть. Или можно сделать у метода дополнительную аннотацию. > Как это аннотацию? Вызовов в методе может быть много, не все будут > хвостовыми.
Ну и помечать "вызов по смещению X — концевой".
> C>Вообще, у .NET тоже куча проблем — сложно реализовать аналог HotSpot, > сложно делать GC для кода (динамические языки — в пролете) — в Sun JVM > есть GC для классов, нет нормального внешнего интерфейса (JNI rulez) и т.п. > Конечо дотнет не идеален. Он вообще — говно. Но по совокупности чуть > меньшее говно, чем Жаба.
Мне на Parrot VM.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, Alexandro, Вы писали:
N>Жабист жабисту друк, но истина дороже...
A>>Специально ради тебя написал небольшой тест: A>>скомпилировал, запустил. A>>результаты: A>>c# — 650ms A>>java — 141ms (-server), 297ms(-client)
N>Тест некорректен т.к. в данном случае был просто inline кода. Для того, чтобы он был несколько более правильным, нужно сделать следующее: N>1. Нужно несколько реализаций Fun, и они должны использоватся. В этом случае нужны будут виртуальные вызовы. Т.е. тест нужно переписать чтобы было несколько "делегатов" и они все участвовали в тесте. N>2. Тело метода вообще пустое. Скорее всего, компилятор его выкинул. Нужно что-то в нем делать более-менее полезное. N>3. В java версии нужно делать warmup (см мои посты выше), иначе ты работаешь на интерпретируемом коде некоторое время.
N>Но, получившийся код все равно не будет неэквивалентен т.к. делегаты имеют доступ к фрейму функции, которая их вызывает, а анонимные методы — нет (только к константам).
N>Вообще, написать корректный микробенчмарк это очень непростое занятие.
согласен. здесь подробнее описано. Смысл в том, что разница в производительности не существенна в подавляющем большинтсве случаев.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, anton_t, Вы писали:
_>>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?
Далее куча перечислений что к чему; хотелось просто поддержать УМНОГО человека, в чем то понимающего.
Основы !
Java = J2ME + J2SE + J2EE |
J2ME — хромает на обе ноги, и даже больше ))
НО на J2SE и J2EE строят МЕГА !!! проекты !!! и говорить что Java хуже — не знать ничего !!!
C# = ASP.NET + WINDOWS FORMS (+ compact framework)
На этом пишут Хорошие сайты, ASP.NET рулит нужно отдать должное, остальное не переносимо, и ничего масштабного вы не увидите , в ближайшем будущем точно ! Новая Виста — это еще одна корова на льду. Но для написания проектов среднего уровня,под Win, вполне подходит.
Теперь скорость !!!
Давайте сравнивать скорость и надежность на нейтральной платформе , так как именно это главные плюсы управляемых , переносимых языков.
ТАК ЧТО КАКУЮ ПЛАТФОРМУ (НЕЙТРАЛЬНУЮ) МЫ ВЫБЕРЕМ !? (Смешно правда ? или подождем еще 3-4 года и тогда соберемся и еще раз сравним ? )
PRV>ТАК ЧТО КАКУЮ ПЛАТФОРМУ (НЕЙТРАЛЬНУЮ) МЫ ВЫБЕРЕМ !? (Смешно правда ? или подождем еще 3-4 года и тогда соберемся и еще раз сравним ? )
Для Java их очень много , а для .NET ...
ВЫВОД (забыл сделать ссори) ! J2SE и J2EE переносимы , .Net — нет )) !!! сравнивать Java'у пока не с чем !!! Модеры, думаю тему можно закрыть ))) .
Здравствуйте, PRoViDeR, Вы писали:
PRV>Здравствуйте, n0name2, Вы писали:
N>>Здравствуйте, anton_t, Вы писали:
_>>>Мда... Ты в курсе какова сложность вставки в середину списка, а какова в середину списка?
PRV>Java = J2ME + J2SE + J2EE | PRV>J2ME — хромает на обе ноги, и даже больше )) PRV>НО на J2SE и J2EE строят МЕГА !!! проекты !!! и говорить что Java хуже — не знать ничего !!!
PRV>C# = ASP.NET + WINDOWS FORMS (+ compact framework) PRV>На этом пишут Хорошие сайты, ASP.NET рулит нужно отдать должное, остальное не переносимо, и ничего масштабного вы не увидите , в ближайшем будущем точно ! Новая Виста — это еще одна корова на льду. Но для написания проектов среднего уровня,под Win, вполне подходит.
Ты уж определись — в одном посте ты пишешь, что .net не переносим, в другом учитываешь только переносимые фичи. Если добавить непереносимые возможности, то имеем:
+WMI
+COM = вся куча написанных COM-библиотек легко доступна под .net
+MSDTC
+создание на .net хранимок для MSSQL и Orale for Win
+сюда же можно новые фичи приплюсовать: WCF, WWF, WPF
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gregory_krovosos, Вы писали:
VD>Да пойми. Я на Шарпе имею скорость приблизительно как на VC++, простоту выше чем на Яве, качественную среду и отладчик, WinForms, ASP.TET и каждый квартал обновляемый МСДН.
VD>Ты же выдвигая предпосылку о том, что можно работать медленно и не удобно спрашиваеш почему другие так не хотят.
VD>Ты лучше сам ответь, а зачем нужна Ява если у нее нет ни одного приемущества?
Эх.. Программил я на java 2 года, потом 2 года на c#. Поначалу вроде прикольно показалось, но под конец мучительно захотелось снова на java. Что я и реализовал, сменив работу.
Пройдемся по пунктам.
1. "скорость приблизительно как на VC++". Скорость чаще не от платформы зависит, а от прямоты рук.
2. " простоту выше чем на Яве". Категорически не согласен. Java намного проще и понятнее. Некоторые чудо-решения от c# до сих пор меня удивляют.
3. "WinForms". Swing куда удобнее для программиста. Да и со скоростью порешали(хотя, конечно, по скорости отрисовки все равно winForms быстрее. Оно и понятно: свинг использует только рисование примитивов из нативных функций, винформы на 90% нативные). Кстати, сейчас пишем программку на свинге.
4. "качественную среду и отладчик". Ну, с этим в java все отлично .
5. "ASP.NET". Подобных технологий навалом. Это тема для отдельного спора.
6. "каждый квартал обновляемый МСДН". Хелп от МС — одна из моих головных болей. Зоопарк страниц, хрен чего найдешь(почему-то гугл ищет по мсдн в разы лучше собственного уродского поисковика). Нужные знания зачастую находятся совсем не там, где их ожидаешь.
Теперь СЕРЬЕЗНЫЕ недостатки дотнета:
1. Кроссплатформенность, точнее ее отсутствие. Это главная причина, по которой мы сейчас пишем софт на java: переписывать его под win и lin не хочет никто, а железяки, на которые будем ставить, могут поставляться с совершенно непредсказуемыми ОС на борту.
2. Нет исходов самого дотнета + слишком много кода в нативе. Иногда концы ошибки не поймать (особенно это проявлялось при работе с глючным compact framework, особенно с учетом очень куцой документации к нему). Эти NullReferenceException, летящие из глубины фреймворка, и совершенная невозможность посмотреть, где, в каком месте стека, на какой строке, и почему произошла ошибка(а также оттрассировать код фреймворка до этого места в тяжелых случаях), выводили из себя неоднократно. Если бы еще не привычка MS оснащать вылетающие исключения совершенно глупыми коментариями...
3. Мог бы еще про IDE написать, но не буду. 2005 студия продукт неплохой(вот до нее реально было плохо). Если бы еще локальную историю сделали...
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, AndreiF, Вы писали:
C>>http://www.jetbrains.com/idea/features/local_history.html AF>Это есть в SlickEdit Tools for Visual Studio http://www.slickedit.com не открывается Плохой знак.
AF>Хотя мне и системы контроля версий хватает
Локальная история более детальная — там детализируются все операции с кодом. Иногда удобно, чтобы найти из-за чего программа перестала работать после пары сотен строк кода.