Здравствуйте, Qbit86, Вы писали:
Q>А потом хоть краем глаза глянь на вменяемые языки и технологии, чтоб осознать костыльную природу Буста и «техник Александреску».
Осталось только озвучить список нормальных языков .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, March_rabbit, Вы писали:
F>>хочется побыть илитой?. F>>изучи буст, покажи шаблонную магию им.Александреску.. и все будут тебе завидовать.. M_>где-то слышал выражение, что магия отличается от колдовства/волшебства/ведовства тем, что маг не понимает сути магии. Просто знает, что каким словом вызвать что-то и все. Имхо, Александреску — это из колдовства
Все с точностью до наоборот. Маги — это фокусники. Их магия — это упорная тренировка или отличный инвентарь. А вот колдуны — это действительно больные на голову люди или обманщики которые творят черти что.
Алексондреску же — это банальный инжинер который пытался подкрутить недоработанный язык чтобы вдохнуть в него жизнь. На сегодня он вроде бы с этим завязал и сейчас участвует в развитии D.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>Затем же зачем и другие аппсервера.
Другие аппсерверы имеют другие цели.
AV>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности.
Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого), только зачем аппсервер как самостоятельная программа?
Hi gandjustas
AV>>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>>Затем же зачем и другие аппсервера. G>Другие аппсерверы имеют другие цели.
AV>>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности. G>Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого),
Да, пришлось и это делать. Вот только платформ там не мало. А COM больше из мира винды. Хотя для некоторых систем есть и коммерческие реализации. Но не для всех.
Здравствуйте, VladD2, Вы писали:
VD>Если бы вы перевели его скажем на Немерле или F# (с умом), то он бы стал еще более лаконичным и читабельным (раз эдак в 5).
Ну так переведи вышепроцитированный код на немерле или f#, а мы поаппладируем в восхищении!
Здравствуйте, ambel-vlad, Вы писали:
AV>Hi gandjustas
AV>>>>>А разные приложения крутятся в разных процессах. Сервер тоже отдельный процесс. Хотя некоторая часть аппсервера находится в одном процессе с приложением. Но эта часть никак не может оказать влияния на работу сервера.
G>>>>Тогда зачем вам аппсервер, если компоненты грузятся в процесс приложения?
AV>>>Затем же зачем и другие аппсервера. G>>Другие аппсерверы имеют другие цели.
AV>
AV>>>Тем более, что работа всех компонентов приложения в пределах одного процесса совсем не обязательное требование. Они могут вообще быть на разных концах света. Но в этом случае будет падение производительности. G>>Так вы изобрели свой вариант компонентной модели типа COM или CORBA (видимо изначальное отсуствтие COM\DCOM на целевой платформе и побудило создание такого),
AV>Да, пришлось и это делать. Вот только платформ там не мало. А COM больше из мира винды. Хотя для некоторых систем есть и коммерческие реализации. Но не для всех.
Здравствуйте, Cyberax, Вы писали:
T>>>>Linq, DLR и др. C>>>Hibernate, JRuby, dynamic invoke. T>>Это тут при чем? C>Аналоги.
Что из этого является аналогом Linq?
T>>Какие там проблемы? C>Он сам ненормальный.
Чем ненормальный?
C>>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. T>>Стало быть обратное работает: все .NET либы автоматически появляются в на яве? C>Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню.
Погоди, у тебя что-то с логикой. Ты утверждаешь, что ява имеет больше библиотек основываясь на факте существования непортированных на нет явовских библиотек. То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек.
Здравствуйте, mrTwister, Вы писали:
T>>>>>Linq, DLR и др. C>>>>Hibernate, JRuby, dynamic invoke. T>>>Это тут при чем? C>>Аналоги. T>Что из этого является аналогом Linq?
Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png
T>>>Какие там проблемы? C>>Он сам ненормальный. T>Чем ненормальный?
Тормозной, особенно при работе с памятью (консервативный GC, однако).
C>>Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню. T>Погоди, у тебя что-то с логикой. Ты утверждаешь, что ява имеет больше библиотек основываясь на факте существования непортированных на нет явовских библиотек.
Да.
T>То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек.
Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>>>Linq, DLR и др. C>>>>>Hibernate, JRuby, dynamic invoke. T>>>>Это тут при чем? C>>>Аналоги. T>>Что из этого является аналогом Linq? C>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png
на картинке жалкое подобие Linq2SQL.
Можно ли такой же запрос написать для коллекции объектов?
Будут ли типы проверяться при компиляции?
Здравствуйте, gandjustas, Вы писали:
C>>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png G>на картинке жалкое подобие Linq2SQL. G>Можно ли такой же запрос написать для коллекции объектов?
Нет (ну если свой провайдер не напишешь). Для XML — можно.
G>Будут ли типы проверяться при компиляции?
Да, на этапе инспекции.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Hibernate с поддержкой IDE — http://files.rsdn.ru/37054/HQLBug.png G>>на картинке жалкое подобие Linq2SQL. G>>Можно ли такой же запрос написать для коллекции объектов? C>Нет (ну если свой провайдер не напишешь). Для XML — можно.
Не надо мне такого счастья.
G>>Будут ли типы проверяться при компиляции? C>Да, на этапе инспекции.
Какой инспекции?
Здравствуйте, Cyberax, Вы писали:
T>>То есть ты говоришь: если существует явовская библиотека, которую не портировали на нет, следовательно в нете меньше библиотек. Но ведь и в дотнете есть библиотеки, непортированные на яву, и, пользуясь твоей логикой, можно сделать вывод, что в яве меньше библиотек. C>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java.
Здравствуйте, gandjustas, Вы писали:
C>>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java. G>Примеры в студию.
Встраиваемый LDAP сервер — из недавнего.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Не совсем. Для некоторых вещей на .NET вообще нет библиотек, хотя они есть для Java. Уникальные для .NET бибилиотеки — обычно слишком спецефичные, чтобы их портировать на Java. G>>Примеры в студию. C>Встраиваемый LDAP сервер — из недавнего.
Учитывая что .NET в полном варианте работает под Windows, то встраивавемый LDAP не сильно нужен так как есть AD.
Это как раз пример слишком специфичного компонента, который .NET не очень нужен.
Здравствуйте, gandjustas, Вы писали:
C>>Нет (ну если свой провайдер не напишешь). Для XML — можно. G> G>Не надо мне такого счастья.
Ну вот просто пока никому не нужно было.
G>>>Будут ли типы проверяться при компиляции? C>>Да, на этапе инспекции. G>Какой инспекции?
Выполнение инспекций кода в IDE.
LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Нет (ну если свой провайдер не напишешь). Для XML — можно. G>> G>>Не надо мне такого счастья. C>Ну вот просто пока никому не нужно было.
Почему на C# всем нужно?
C>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей.
Это вам так кажется потому что Linq полноценно не пользовали.
Здравствуйте, gandjustas, Вы писали:
G>>>Примеры в студию. C>>Встраиваемый LDAP сервер — из недавнего. G>Учитывая что .NET в полном варианте работает под Windows, то встраивавемый LDAP не сильно нужен так как есть AD.
Только вот нужен был LDAP для специального сервера, который должен работать параллельно с AD, предоставляя некоторую очень специфическую функциональность.
G>Это как раз пример слишком специфичного компонента, который .NET не очень нужен.
Да-да. Как видишь, мне вот оказалось нужно.
Для Java таки решение сразу же нашлось — http://wiki.interldap.objectweb.org/xwiki/bin/view/Main/ Пришлось по-быстрому написать всё нужное на Java и интегрировать через локальные веб-сервисы. Жуть, в общем — хорошо что это приложение не нужно было распространять.
Прелесть LInq — это не ORM, а возможность писать статически типизированные запросы с единым стандартным синтаксисом к любым источникам данных и не надо никаких ИДЕ, провайдеров и пр.
C>Тормозной, особенно при работе с памятью (консервативный GC, однако).
Зато, в отличии от .Net Framework, поддерживает расширенные инструкции процессоров (SSE, например). Да и проигрыш в производительности по памяти имхо не фатальный.
Здравствуйте, gandjustas, Вы писали:
G>>>Не надо мне такого счастья. C>>Ну вот просто пока никому не нужно было. G>Почему на C# всем нужно?
Потому что в C# не умеют пользоваться Hibernate. Вон, даже целый Entity Framework из-за этого начали писать, и забросили LINQ2SQL.
C>>LINQ, конечно, более мощный. Но тут случай, что IDEA — это good enough для большинства целей. G>Это вам так кажется потому что Linq полноценно не пользовали.
Я его использовал. Ещё раз повторяю — в Java для большинства случаев Hibernate вполне хватает.
.
