Здравствуйте, MxKazan, Вы писали:
C>>А кому в MS мне делать багрепорт? Я не знаю, чтобы у них был публичный багтрекер, где я бы мог следить за состоянием баги. MK>http://support.microsoft.com/gp/hublist/
Ага, и меня пошлют к поддержке OEMа. Которая, вроде в Англии, заутсорсеная в Индию, где мне час придётся слушать индуса, читающего по бумажке. Оно мне надо?
MK>Не знаю что там с трекером. Для WPF периодически натыкаюсь на подобное, но ссылку не вспомню. MK>Для грядущей Студии 2010 инсайдеры приводили на форуме линк куда слать сообщения об ошибках.
Так проблемы не в Студии.
Здравствуйте, MxKazan, Вы писали:
C>>У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким. MK>Всё это демагогия. Так ведут себя тонны разного софта под Винду, но их никто за это не клеймит.
То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
MK>Да и написал я только о том, что если о проблеме не знает разработчик, то и решения этой проблемы требовать неправильно. Нам ли об этом не знать Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка?
К программе установки Sun JVM у меня вопросов никогда не возникало, например.
Здравствуйте, gandjustas, Вы писали:
C>>Вот поэтому .NET — он портабельный только в теории, а не на практике. G>Стоп, а кто-то говорил про портабельность всего .NET? Даже маркетологи MS о таком говорят очень осторожно. G>Разговор ведь начался с того что на C# можно вести разработку на любой ОС, но никто не говорил о 100% кроссплатформенности любого кода на C#.
Его нужно специально разрабатывать, аккуратно следя за портируемостью. И тут оказывается, что он не особо-то и лучше QT.
* C#: Most widely used CLI language, bearing similarities to C++ and Java. Implementations provided by .NET Framework, Portable.NET and Mono.
* C++/CLI: A version of C++ including extensions for using CLR objects. Implementation provided only .NET Framework. Can produce either CIL-based managed code or mixed-mode code that mixes both managed code as well as native code. The compiler is provided by Microsoft.
* F#: A multi-paradigm CLI language supporting functional programming as well as imperative object-oriented programming disciplines. Variant of ML and is largely compatible with OCaml. The compiler provided by Microsoft.
* J#: A CLS-compliant implementation of Java. The compiler is provided by Microsoft. Microsoft has announced that J# will be discontinued.
* Windows PowerShell: An object-oriented command-line shell. PowerShell can dynamically load .NET assemblies that were written in any CLI language. PowerShell itself uses a unique scripting syntax, uses curly-braces, similar to other C-based languages.
* JScript.NET: A CLI implementation of ECMAScript version 3, compatible with JScript. Contains extensions for static typing. Deprecated in favor of Managed JScript.
* IronPython: An open-source CLI implementation of Python, currently being re-designed to leverage the DLR.
* IronRuby: An open-source CLI implementation of Ruby, built on top of the DLR.
* Managed Extensions for C++: A version of C++ targeting the CLR. Deprecated in favor of C++/CLI.
* Managed JScript: A CLI implementation of JScript built using the Dynamic Language Runtime. Conforms to ECMAScript version 3.
* VBx: A dynamic version of VB.NET built on top of the Dynamic Language Runtime. See VBScript and VBA as this could be thought of being used like a Managed VBScript (though so far this name has not been applied to this) and could be used to replace VBA as well.
* VB.NET: A redesigned, object-oriented dialect of Visual Basic. Implementations provided by .NET Framework and Mono.
* A#: CLI implementation of Ada.
* Boo: A statically typed CLI language, inspired by Python.
* Cobra: A CLI language with both static as well as dynamic typing.
* Oxygene: An Object Pascal-based CLI language.
* Component Pascal: A CLI language inspired by Pascal and Oberon.
* IronLisp: A CLI implementation of Lisp. Deprecated in favor of IronScheme.
* L#: A CLI implementation of Lisp.
* Lexico: A didactic in Spanish object-oriented language.
* Mondrian: A CLI based functional language designed to provide an easy way of scripting components.
* Nemerle: A functional/imperative hybrid language similar to C#, Perl and Lisp.
* P#: A CLI implementation of Prolog
* Phalanger: An implementation of PHP with extensions for ASP.NET
* Phrogram: A custom CLI language for beginners and intermediate users produced by The Phrogram Company
* PowerBuilder: Can target CIL since version 11.1.
* #S — A CLI language that implements Scheme (a port of Peter Norvig's Jscheme).
* #Smalltalk — a CLI implementation of Smalltalk
* AVR.NET — a CLI implementation of RPG
* Active Oberon — a CLI implementation of Oberon
* APLNext — a CLI implementation of APL
* Common Larceny- a CLI implementation of Scheme
* Delphi.NET — a CLI language implementation of the Delphi language.
* Delta Forth .NET — a CLI implementation of Forth from Dataman
* DotLisp — a CLI language inspired by Lisp
* EiffelEnvision — a CLI implementation of Eiffel
* Fortran .NET: Fortran compiling to .NET
* Gardens Point Modula-2/CLR — an implementation of Modula-2 that can target CIL
* Haskell for .NET — a CLI language inspired by Haskell
* Haskell.net — an upcoming CLI language inspired by Haskell
* Hugs for .NET — a CLI language inspired by Haskell
* IronScheme — a R6RS compliant Scheme implementation based on parts of the Microsoft DLR (about 15% and shrinking)
* Ja.NET — an open source implementation of a Java 5 JDK (Java development tools and runtime) for .NET
* LOLCode.NET — a CLI implementation of LOLCODE
* Lua.NET — a CLR implementation of Lua. There is also Nua for DLR.
* Mercury on .NET — an implementation of Mercury that can target CIL
* Net Express — a CLI implementation of COBOL
* NetCOBOL — a CLI implementation of COBOL
* OxygenScheme — a CLI implementation of Scheme
* S# — a CLI implementation of Smalltalk
* IoNET — a CLI implementation of Io
* PL/IL — a CLI implementation of PL/I
* sml.net — a CLI implementation of Standard ML
* Wildcat Cobol — a CLI implementation of COBOL
* X# — a CLI implementation of ASM developed for Cosmos. X# was also the codename for the XML-capabilities of Cω.
T>>Linq, DLR и др. C>Hibernate, JRuby, dynamic invoke.
Это тут при чем?
T>>У Моно тоже все нормально. C>Нет.
Какие там проблемы?
C>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось.
Стало быть обратное работает: все .NET либы автоматически появляются в на яве?
Здравствуйте, Cyberax, Вы писали:
C>Только вот Java не играет роль "догоняющего".
Роль догоняющего — это даже плюс. Можно избежать чужих ошибок.
C>Как ты думаешь, что будут использовать пользователи MS — интегрированые с VisualStudio продукты или OpenSource-решения, которые не интегрированы и по которым нет тысяч книг "Изучи blah-blah за 21 день"?
Что посчитают нужным, то и будут использовать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MxKazan, Вы писали:
C>>>У MS сплошные проблемы с устойчивостью и дизайном софта. Для установки .NET Runtime оно лезет куда попало, ставит какие-то системные сервисы оптимизации байт-кода и т.п. Естественно, всё это получается весьма хрупким. MK>>Всё это демагогия. Так ведут себя тонны разного софта под Винду, но их никто за это не клеймит. C>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
Что мешало его сделать как Sun JVM не знаю, не задумывался, наверняка есть причины. Пока на вскидку могу сказать, что FW — это не просто набор файлов. Там еще и средства администрирования, редиректы версий сборок. И в конце концов, хотите вы того или нет, но постепенно Win XP отомрёт, а новые ОС Микрософта уже содержат FW.
G>А почему тогда java не взяли, вот уж она есть почти везде?
Да, Java, в принципе — тоже вариант.
C++ был выбран из соображений наименьшего риска проблем с производительностью в сочетании с хорошими перспективами портируемости.
Все-таки, на практике, если не вдаваться в крайние случаи, с C++ меньше вероятность попасть в ситуацию, когда проект не может быть сдан вовремя, так как возникли непреодолимые в течение приемлемого срока проблемы с использованием памяти или быстродействием. Плюс-минус, с C++ можно быть уверенным, что код все-таки удастся оптимизировать до нужного уровня. С Java по этому параметру сложнее.
Кроме того, с J2ME тоже не все так просто. Я слышал леденящие душу истории от многих разработчиков игр на J2ME, как они в целях оптимизации программы уменьшали число классов в программе.
В такой ситуации программирование на Джаве — еще большая головная боль, чем на C++. То есть в данном случае мы получаем уровень абстракции, с которым потом боремся, вместо того, чтобы получать от него выгоду.
Кстати, я, хоть и имею большой опыт разработки на C++, не являюсь упертым адептом этого языка или вообще какой-либо одной технологии.
Я считаю, что любой достаточно квалифицированный программист способен менять инструменты разработки, коими, в том числе, являются и языки программирования, в зависимости от требований конкретной задачи, не испытывая особенных трудностей.
Мне очень нравятся и Java, и C#.
C# я вообще считаю великолепным языком. Я бы с удовольствием писал бы на нем все свои приложения, будь он действительно кроссплатформенным.
Сейчас я вообще подумываю о том, что надо действительно верхнюю часть кроссплатформенного приложения, включающую бизнес-логику и UI писать на чем-нибудь вроде Питона, и только самые критичные для быстродействия части — на C++.
C>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. http://csharp-source.net/open-source/rule-engines
это знаю
остальные были не нужны (аналоги как из джавы, которые вы писали) поэтому, где они обитают — не знаю.
Здравствуйте, Cyberax, Вы писали:
C>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM?
Спасибо, но лучше не надо. Та ещё кривень...
C>К программе установки Sun JVM у меня вопросов никогда не возникало, например.
Редко ставите видать, да в стерильных условиях Вот у меня возникало, и много. К инсталлятору .NET, впрочем, тоже претензий хватает. Начиная с 3.5 там знатный бардак в этом моменте учинили.
Здравствуйте, drol, Вы писали:
C>>То что под Виндой куча кривого софта — не оправдывает кривость установщика .NET FW. Что мешало сделать его как Sun JVM? D>Спасибо, но лучше не надо. Та ещё кривень...
Чем?
C>>К программе установки Sun JVM у меня вопросов никогда не возникало, например. D>Редко ставите видать, да в стерильных условиях Вот у меня возникало, и много. К инсталлятору .NET, впрочем, тоже претензий хватает. Начиная с 3.5 там знатный бардак в этом моменте учинили.
Для клиентов её вообще не ставим — она без установки идёт вместе с приложением. Приложение обычным NSIS'ом ставится.
Здравствуйте, vit.rsdn, Вы писали:
C>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. VR>http://csharp-source.net/open-source/rule-engines VR>это знаю VR>остальные были не нужны (аналоги как из джавы, которые вы писали) поэтому, где они обитают — не знаю.
Я их тоже знаю. Только вот одна маленькая проблема. Единственный из них сколь-либо нормальный — это Drools.NET. И он тоже совсем недоделаный до неюзабельности.
Здравствуйте, mrTwister, Вы писали:
C>>Только вот Java не играет роль "догоняющего". T>Роль догоняющего — это даже плюс. Можно избежать чужих ошибок.
На практике — большой минус. Так как является большим препятствием.
C>>Как ты думаешь, что будут использовать пользователи MS — интегрированые с VisualStudio продукты или OpenSource-решения, которые не интегрированы и по которым нет тысяч книг "Изучи blah-blah за 21 день"? T>Что посчитают нужным, то и будут использовать.
Ну вот поэтому OpenSource под .NET, конкурирующий с продуктами MS — это весьма странное занятие.
Здравствуйте, mrTwister, Вы писали:
T>>>Отсутствие привязки к языку программирования C>>Ага, с богатым выбором языков: C# или VB. T>http://en.wikipedia.org/wiki/List_of_.NET_languages
В списке языков для JVM что-то около тысячи штук их было ещё 8 лет назад.
Смысла только в них мало.
T>>>Linq, DLR и др. C>>Hibernate, JRuby, dynamic invoke. T>Это тут при чем?
Аналоги.
T>>>У Моно тоже все нормально. C>>Нет. T>Какие там проблемы?
Он сам ненормальный.
C>>Судорожно искал для .NET нужные аналоги библиотек, которыми я успешно пользовался в Java. Я привёл примеры того, что мне понадобилось. T>Стало быть обратное работает: все .NET либы автоматически появляются в на яве?
Откуда такой вывод? Многие библиотеки изначально появляются в Java, а потом портируются в .NET. Обратных примеров я, честно говоря, даже не припомню.
Здравствуйте, gandjustas, Вы писали:
G>>>"знаком c С# .NET" — это почитал статью в википедии? G>>>"после осознания политики MS" — это почитал ЛОР? F>>я так понял, про питон ты даже этого не сделал G>Конечно не сделал, я только написал пару программ на питоне для саморазвития, но руби мне больше приглянулся.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>>>Отсутствие привязки к языку программирования C>>>Ага, с богатым выбором языков: C# или VB. T>>http://en.wikipedia.org/wiki/List_of_.NET_languages C>В списке языков для JVM что-то около тысячи штук их было ещё 8 лет назад. C>Смысла только в них мало.
И тем не менее, приведенный список подтверждает "отсутствие привязки к языку программирования"...
Да, это правда. Мне вот, например, приходилось делать нелёгкий выбор между увеличением .jar'а с midlet'ом на 2.5Кб (вследствии разделения "толстого" класса на два), и возможностью нормально пользоваться IntelliJ IDEA (она дико тормозила на большом "монолитном" исходнике).
*Выбрал второе. JetBrains навсегда
А что Вас так пугает ? Это всего-лишь следствия ограничения конкретных платформ. Ежели 32Кб на midlet выдают, то там каждый байт даже метаданных на счету. На C++ приходилось бы экономить ровно в том же духе. То бишь никаких тебе STL/boost, всё на статических массивах и т.д.
К>В такой ситуации программирование на Джаве — еще большая головная боль, чем на C++.
Это в лучшем случае та же самая боль. А обычно хуже, бо даже базовые API J2ME позволяют очень много чего делать "одним росчерком", в отличии от C/C++ аналогов.
К>C# я вообще считаю великолепным языком. Я бы с удовольствием писал бы на нем все свои приложения, будь он действительно кроссплатформенным.
На мой взгляд, в большинстве случаев кроссплатформенность в Вашем понимании вообще не нужна. Это даже не касаясь момента, что в реале всё равно ведь получается "write once, debug everywhere". И надо точить...
Hi gandjustas
S>>>>>Что вы называете "взаимодействием"? AV>>>>Из кода, написанного на одном языке, дернуть код, написанный на другом языке. G>>>Для этого уже существует много способов, самый универсальный — ws-* вебсервисы, инфраструктуру создавать не надо, оно уже есть. G>>>На вебсервисах есть сотни систем, которые работают в том числе под высокой нагрузкой.
AV>>В случае заказчика этой скорости не хватало. Поэтому и пришлось создавать свою инфраструктуру.
G>Мне кажется что проблема у вас изначално была в том что интероп требовался слишком часто, при этом вместо выпрямления архитектуры вы решили делать свой аппсервер.
Начнем с того, что не у нас, а у заказчика. И насколько мне известно, то с архитектурой там все нормально. Так тобой любимые веб-сервисы там точно никаким боком не помогли бы. В подробности вдаваться не могу, так как эту информацию я получил из личных знакомств и не считаю возможным ее разглашать. Так что придется поверить на слово.
И никто первоначально не городил целый апп-сервер. Сначала там была лишь небольшая подсистема, для решения основной цели. И лишь потом эта подсистема трансформировалась и выделилась в отдельный сервер.
Hi gandjustas
AV>>>>А одного процесса? G>>>А в пределах одного процесса я бы не стал запускать managed и unmanaged код.
AV>>Почему? Если уверен к качесте unmanaged кода? G>Ну если весь код я писать буду, то тогда будут писать на одном языке и проблем не будет.
Вот видишь, а другие могут писать на нескольких языках. В зависимости от того, что должен делать модуль.
G> А если кто-то другой, то в принципе не могу быть уверенным что не упадет unmanaged и не утянет за собой кучу managed модулей.
AV>>И тем более есть возможность в случае необходимости в течении пары секунд сделать так, чтобы unmanaged код выполнялся в отдельном процессе? G>Тогда не совсем понял как реализован интероп, если так просто вынести в отдельный процесс.
Ничего сложного в этом нет. Если невдаваться в подробности, то в момент создания компонента определяется где он должен располагаться и далее от этого пляшем.
AV>>А если есть два куска managed кода, но на разных языках? G>SOA и пайпы\TCP\HTTP как транспорт.
Не все ложится на SOA. Далеко не все.
Далее, зачем использовать пайпы\TCP\HTTP как транспорт в пределах одного процесса, если есть возможность задействовать более быстрые механизмы?
Или здесь только у меня не получалось создать серьезную и при этом абсолютно безглючную программу, на которую заказчик не написал ни одного фидбэка?
Вот у меня возникало, и много. К инсталлятору .NET, впрочем, тоже претензий хватает. Начиная с 3.5 там знатный бардак в этом моменте учинили.
