LINUX.ORG.RU

[не троллинга ради] чем плох дотнет


0

3

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

★★
Ответ на: комментарий от ef37

Это не писькомерство. Все те товарищи, которые там перечислены оказывают значительное влияние на java.

А, ну вот оно что. Так и надо говорить, что это не страница тех кто юзает жабу, а страница тех, кто оказывает на нее влияние. Тогда для дуднета эта страница очевидно состояла бы из самого микрософта.

Кстати, в JCP есть и частные лица, не только корпорации. А вот скажи как, можно вот так вот прийти в MS и сказать а давайте запилим блэкджек и шлюх фичу в дотнете ? Любой вендор может ? И вообще эта процедура стандартизована ?

Дуднет проприетарен и, естественно, микрософт вынужден учитывать пожелания своих клиентов. Результат на лицо - дуднет активно развивается, пока жабадебилы спорят и голосуют на основе «стандартизированных процедур». То есть в случае дуднета никаких таких процедур нет - но твои пожелания будут учтены. В случае жабы процедуры есть и твои пожелания будут «приняты к сведению». И забыты. Выбирай - что лучше.

anonymous
()
Ответ на: комментарий от anonymous

Дуднет проприетарен и, естественно, микрософт вынужден учитывать пожелания своих клиентов.

Ага, какое удачное слово - вынужден. Да им чихать на клиентов - типа как скажем так и будет. Помнится до текущей версии несколько раз ломали бинарную совместимость - да так что нужно было держать по несколько версий рантайма на клиенте.

Результат на лицо - дуднет активно развивается, пока жабадебилы спорят и голосуют на основе «стандартизированных процедур». То есть в случае дуднета никаких таких процедур нет - но твои пожелания будут учтены.

Скажет так - активно развивается исключительно силами MS. Нет бы бл..., тот же Mono спонсировать. Пожелания будут учтены - а может и не будут. Как заблагорассудится. Никакой прозрачности.

ef37 ★★
()
Ответ на: комментарий от ef37

Скажет так - активно развивается исключительно силами MS. Нет бы бл..., тот же Mono спонсировать. Пожелания будут учтены - а может и не будут. Как заблагорассудится. Никакой прозрачности.

На самом деле MS плевать на Mono. Ведь если они будут спонсировать реализацию .NET под linux, то это соответственно скажется на продажи сами знаете какой ОС для Майкрософта. Ведь M$ linux-based дистрибутивами пока славу богу не торгует.

Ага, какое удачное слово - вынужден. Да им чихать на клиентов - типа как скажем так и будет. Помнится до текущей версии несколько раз ломали бинарную совместимость - да так что нужно было держать по несколько версий рантайма на клиенте.

Абсолютно точно. Цель M$ - это как можно сильнее снизить уровень вхождения в технологию. Тут тебе и куча литературы (читай - для умственно отсталых товарищей, которые даже тех. литературу на английском не осиливают). Тут тебе и куча видеороликов на сайте самой МС и бесплатный урезанный софт для «профессиональной» разработки. Чудеса. Самое интересное что сколько либо значимых проектов построенных на этой платформе я почему то не наблюдаю.

anonymous
()
Ответ на: комментарий от anonymous

На самом деле MS плевать на Mono. Ведь если они будут спонсировать реализацию .NET под linux, то это соответственно скажется на продажи сами знаете какой ОС для Майкрософта. Ведь M$ linux-based дистрибутивами пока славу богу не торгует.

А Sun надо полагать - «жавадебилы» и на кой-то хрен пилили HotSpot JVM и для линукса в том числе. MS уже торгуют linux-based дистрибутивами - в частности SuSE в партнерстве с Novell.

ef37 ★★
()
Ответ на: комментарий от ef37

Скажет так - активно развивается исключительно силами MS.

Какая разница чьими? Главное результат.

Пожелания будут учтены - а может и не будут.

Так и с жабой очевидно. Но в случае дуднета шанс выше.

anonymous
()
Ответ на: комментарий от anonymous

На самом деле MS плевать на Mono.

Зачем же они тогда его поддерживают? Если бы мс захотели, то уже завтра моно бы кончился.

Цель M$ - это как можно сильнее снизить уровень вхождения в технологию. Тут тебе и куча литературы (читай - для умственно отсталых товарищей, которые даже тех. литературу на английском не осиливают). Тут тебе и куча видеороликов на сайте самой МС и бесплатный урезанный софт для «профессиональной» разработки.

Охренеть. Оказывается, наличие качественных обучающих материалов - это плохо. Прыщебляди вконец уже охуели.

Самое интересное что сколько либо значимых проектов построенных на этой платформе я почему то не наблюдаю.

На платформе джавы сколько-нибудь значимых проектов я тоже не наблюдаю.

anonymous
()
Ответ на: комментарий от anonymous

Какая разница чьими ?

Разница в том, что взгляды разносторонние, да и участвующих побольше.

Так и с жабой очевидно. Но в случае дуднета шанс выше.

С чего бы вдруг ?

ef37 ★★
()
Ответ на: комментарий от anonymous

Ты видимо не понимаешь. Под .NET нет того многообразия библиотек и фреймворков что существует для платформы JVM. Все что может предоставить .NET - это пару фреймворков для клепания формочек и раздутый и обильно посыпанный сахарком язычок C#.

anonymous
()
Ответ на: комментарий от anonymous

Под .NET нет того многообразия библиотек и фреймворков что существует для платформы JVM.

«Того многообразия наколеночных опенсорсных поделок» - так будет вернее. С качественными библиотеками в C# все обстоит лучшим образом.

anonymous
()
Ответ на: комментарий от anonymous

Стоп, стоп. Ты сначала взгляни, какие конторы юзают тот же Hadoop или Mahout, а потом делай такие громкие заявления. Ведь для .NET ничего аналогичного не существует.

anonymous
()
Ответ на: комментарий от anonymous

Кривые подделки с codeproject'a (я недавно нашел что-то отдаленно похожее для .NET), которые разрабатываются одним человеком я за альтернативу не считаю по нескольким причинам:

1) Разработка ведется дай бог парой человек. 2) Их разработку никто в всерьез не использует (посмотри на Hadoop или Mahout\Weka, такие гиганты как Yahoo, Google, Ebay, и фондовая биржа Лондона уже вселяет уверенность в данный проект) 3) Проект не поддерживается серьезными компаниями. Хотя нет не так, он не поддерживается вообще никакими компаниями (Тот же Hadoop поддерживает и активно развивает Yahoo).

Все это мне дает понять, что подобные разработки под .NET жалки и убоги. В лучшем случае это забава для студентов которые решили поиграться с языком\платформой.

anonymous
()
Ответ на: комментарий от anonymous

Так кроме того же hadoop и пары других подобных поделок жаба может хоть чем-то похвастаться? Аж два успешных проекта - как-то несерьезно. Тут и меряться-то нечем, жаба сливает дуднету даже не начав борьбу.

anonymous
()
Ответ на: комментарий от anonymous

Ты делаешь мне смешно. Ну загляни ты на апачевский сайт и посмотри что за проекты у них хостятся. Cassandra, Lucene, IText, тысячи их. А твой C# можно похвастаться только тем, что на нем удобно формы клепать. Вся реализация более менее серьезного софта, фреймворков завязана на M$. У Java это не так. Есть Apache, Oracle, RedHat, IBM. Если мне что-то не понравиться у одного вендора, я смогу перейти к другому. В случае твоего божественного C# такого выбора не будет.

anonymous
()
Ответ на: комментарий от anonymous

Ну загляни ты на апачевский сайт и посмотри что за проекты у них хостятся.

Какое отношение это имеет к теме разговора?

А твой C# можно похвастаться только тем, что на нем удобно формы клепать.

Ну джава даже этим похвастаться не может, как мы уже выяснили.

Вся реализация более менее серьезного софта, фреймворков завязана на M$.

И это огромный плюс, по сравнению с разбродом, творящимся с жабой.

anonymous
()
Ответ на: комментарий от quantum-troll

- Mono на пару порядков меньше любой JVM.

- Никакой стековой VM там и не пахнет.

- Хорошая, правильная модель памяти, подходит для функциональщины.

- Mono заметно полноценнее чем оригинальный MS.NET

Так что, тролль, ты неграмотный баран и не более того.

anonymous
()
Ответ на: комментарий от quantum-troll

Компиляторы пишут. А потом ява-машина не осиливает толком оптимизировать это для реальной машины, и в итоге результат ТОРМОЗИТ.

Ты хотя бы отдаленно представляешь себе, как вообще JIT устроены? Там все равно все неизбежно в SSA переводится. От стекового представления ничего даже в JVM не остается (а в .NET его и нет вовсе).

anonymous
()
Ответ на: комментарий от unfo

Лгать плохо, сопляк. Запомни это. mono и .net полностью совместимы. В mono нет некоторых (на хер не нужных) библиотек, в основном всякой гуйни, ну так на .net и не надо гуйню писать.

anonymous
()
Ответ на: комментарий от Ttt

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

anonymous
()
Ответ на: комментарий от ak369260

Лошара, не тупи. JVM интерпретируется (и под интерпретацию заточен). JIT не обязателен. А вот IL интерпретировать эффективно нельзя, он изначально заточен под компиляцию. Потому и JIT у них такие разные - HotSpot профилирует сначала процесс интерпретации, выбирает только наиболее нагруженные участки кода и компилирует их, а JIT для .NET компилирует все и сразу.

anonymous
()
Ответ на: комментарий от netcat

Ты этюды nikov-а видел, да? И все равно «простой язык»?!?

anonymous
()
Ответ на: комментарий от anonymous

Только вот все альтернативные языки под JVM или жуткие тормоза или семантические выродки (как Clojure, например, с его уродливым «recur»).

anonymous
()
Ответ на: комментарий от anonymous

Ущербный недоумок слышал про iKVM? Нет? Ну погугли, сявка.

Все, написанное для JVM, однозначно транслируется в .NET. В обратную сторону это не работает, так как .NET - существенно более мощная платформа.

anonymous
()
Ответ на: комментарий от anonymous

HotSpot профилирует сначала процесс интерпретации, выбирает только наиболее нагруженные участки кода и компилирует их

преобразует код метода при первом обращении в машинный

Твои мозги, хамло, не в состоянии увидеть, что это одно и то же, различное только в деталях?

И разницу в заточенности и в том, что происходит в реальности ты, хамло, совсем не осиливаешь видеть?

А то, что, кроме HotSpot'а, существуют другие JIT с другой алгоритмикой работы ты, судя по всему, не слышал?

Ты, хамло, можешь только безлико срать из-под анонимуса.

ak369260
()
Ответ на: комментарий от anonymous

Все, написанное для JVM, однозначно транслируется в .NET. В обратную сторону это не работает, так как .NET - существенно более мощная платформа.

Судя по очень характерному хамству и еще более характерной нелюбви к JVM и любви к .NET, можно предположить, что нас тут осчастливил посещением один легендарный в прошлом персонаж.

ak369260
()
Ответ на: комментарий от ak369260

Але, придурок, читать научись: JVM делали изначально под интерпретацию. А .NET намного проще и тупее, и интерпретировать его нельзя. Включи мозги, кретин.

anonymous
()
Ответ на: комментарий от anonymous

Как сказал, так оно и есть - методы в JVM компилируются в нативный код. Вся остальная информация к этому высказыванию в данном контексте отношения не имеет.

Что так бесишься, начала болеть попа?

ak369260
()
Ответ на: комментарий от anonymous

Ты глуп в абсолюте. Посмотри как происходит компиляция в нативный код. Этим процессом можно очень гибко управлять, вплоть до указания JVM, что компиляцию в нативный код нужно организовать после первого вызова метода. У .NET же априори ничего похожего нет.

Да, после первого вызова метода, он будет скомпилирован в нативный код, ну и что дальше? У JVM есть опция -Xbatch, которая делает ровным счетом тоже самое. Т.е компиляция в нативный код будет происходить еще до вызова этого самого метода, т.е это как некий аналог утилиты ngen для .NET.

Ну и конечно все вкусняшки, которыми не обладает .NET здесь тоже есть. Полный контроль над JVM, не понравился одни алгоритм сборки мусора - пожалуйста, на выбор будет еще два-три. Нужно выделить больше памяти машине - без проблем. Перенос процесса сборки мусора на другое ядро машины, выделение памяти, опции server, client. Вот где .NET сливает по полной.

О тормозах таких языков как Scala, Clojure. За Clojure я ничего сказать к сожалению не могу, ты взгляни на производительность Scala, а особенно обрати свое внимание на реализацию акторов и какой буст это дает для разработки распределенных приложений. Можно разбить свое приложений на миллионы нод, которые могут работать на разных тачках и при этом все будет быстро и надежно. Т.е получаем некий аналог Erlang, с его легковесными «процессами», но с полным боекомплектом библиотек и фреймворков, которые предлагает платформа JVM.

anonymous
()
Ответ на: комментарий от ak369260

Разбегись в стену, придурок. Разговор был за принципиальную разницу в дизайне VM. Как результат этой разницы, компиляция JVM заметно дороже стоит.

anonymous
()
Ответ на: комментарий от anonymous

Нет нет, ты не понял. У .NET, а в частности CLR, которая занимается интерпретацией и дальнейшей компиляции в нативный код, попросту отсутствуют какие либо параметры, которые можно задать, что бы было «круто». Все что я нарыл в интернете, это жалкая статья о том, как разделить кучу на два ядра и что то там про конфигурационный файл, в котором можно задать только параметры для уже упомянутого тобой GC. Выделить больше памяти или ограничить ее у тебя в .NET не получится. Перенести процесс сборки мусора на другое ядро - та же история. Выбрать иной алгоритм сборки мусора - опять нет.

anonymous
()

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

ZenitharChampion ★★★★★
()
Ответ на: комментарий от anonymous

Только вот все альтернативные языки под JVM или жуткие тормоза или семантические выродки (как Clojure, например, с его уродливым «recur»).

Лучше, чем ничего. Под .NET есть нормальный Лисп?

anonymous
()
Ответ на: комментарий от anonymous

IronScheme

к нормальным лиспам не относится.

Bigloo

Он есть под .net? Ну тогда замечательно.

anonymous
()
Ответ на: комментарий от anonymous

А теперь задайся вопросом, кому этот mono нужен, кроме как энтузиастам, которые решили C#, на linux-based os погонять. Я даже не говорю о том, что мне так и не удалось найти крупные конторы которые поддерживают компанию Xamarin, которая если я не ошибаюсь курирует проект mono.

anonymous
()
Ответ на: комментарий от quantum-troll

Какая разница на сколько оно меньше в размере? Как будто это кого-нибудь интересует. Главное что под эту платформу имеется просто нереальное количество полезных библиотек\фреймворков. Под .NET того многообразия нет. Оно либо продается за деньги какими то левыми компаниями, либо разработано самой M$, которая не торопиться обеспечить ребят которые юзают C#(.NET), что бы у них были библиотеки на все случаи жизни, а не только сахарок которого в языке с избытком. Как будто это ускорит написание проекта, наивные.

anonymous
()
Ответ на: комментарий от anonymous

Если и счесть clojure лиспом (что сомнительно уже само по себе), то «нормальным» лиспом это костыльное поделие не будет даже с натяжкой.

anonymous
()
Ответ на: комментарий от anonymous

Формально это диалект лиспа. Если что-то не устраивает welcome - есть Common Lisp. Правда с Clojure, у тебя будут все батарейки платформы Java, а вот с Common Lisp'ом только скобочки. Ах да, коммерческих проектов на Clojure в разы больше чем на CL и это не интерпрайз, а в основном проекты связанные с data mining/map reduce.

anonymous
()
Ответ на: комментарий от anonymous

Если и счесть clojure лиспом (что сомнительно уже само по себе), то «нормальным» лиспом это костыльное поделие не будет даже с натяжкой.

REPL есть, макросы есть. Что еще надо?

anonymous
()
Ответ на: комментарий от anonymous

Он нужен всем, кто хочет генерить эффективный код в рантайме. Например, Second Life. Как vm mono встраивается на порядок удобнее всех прочих.

anonymous
()
Ответ на: комментарий от anonymous

Еще раз, придурок. ЛЮБАЯ Java библиотека может использоваться из .net. А вот обратное невозможно.

anonymous
()
Ответ на: комментарий от anonymous

Понятно все с тобой. Игрушечки начал приводить в качестве аргументов. Все с тобой ясно. Продолжай зарабатывать на жизнь кодингом на похапе, а в обеденный перерыв наслаждайся православностью .net муахах.

anonymous
()
Ответ на: комментарий от anonymous

Что происходит в твоем маленьком мозгу? Тебе говорят про разработку проектов на Java и что ее поддерживают куча корпораций. А ты в ответ тыкаешь этим IKVM'ом, который всего навсего транслирует байт-код Java в MCIL. Это выглядит как попрошайничеством. Не забудь когда выйдет новый релиз Hadoop, HBase или Mahout'a конвертнуть его в MCIL и рассказать ребятам как ты круто юзаешь Java либы муахаха.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.