Нафига козе боян?
Я не прошу в ответах кидать сюда ссылки на другие сайты где можно почитать длинные, пространные и замудрёные статьи о точканете. Я хочу услышать ПРОСТОЙ и по-возможности КОРОТКИЙ ответ на вопрос озвученный выше. Заранее благодарю.:)
Деньги зарабатывать. Но будь я модератором, ваш топик уже отправил бы в топку.
Деньги можно и без программирования в точкаНете зарабатывать. Я имею ввиду для каких программистких целей?
З.Ы. Хорошо, что вы не модер.
Возможности дотнета вытекают не из "некомпилируемости" в машинный код - CIL код в конечном счете (NGEN-ом или JIT-компилятором) компилируется под конечную аппаратную платформу - а из "богатого внутреннего мира": наличия метаданных для всего. Именно благодаря наличию метаданных работает сборка мусора и механизмы рефлексии.
По поводу кроссплатформенности. Для начала надо определиться с термином "платформа" - это аппаратная платформа (архитектура компьютера) или программно-аппаратная (ОС + архитектура компьютера)?
Если первое, то MS сделала JIT компиляторы для x86, AMD64, Itanium и ARM (для мобильников я к сожалению не в курсе). По поводу второго толкования, взгляни на MonoDevelop. ;)
там динамическое изменение кода и прочее
Простите? Какое такое динамическое изменение? Да, в рантайме можно сгенерировать сборку и запустить ее на исполнение, а вот подмена методов - это уже что-то из разряда глубоких хаков применимых к совершенно конкретным CLR.
Можно. Но, я уверен, большинство юзеров этого ресурса хотели бы (и у них получается) зарабатывать именно этим.
Я самореализовался за 9 месяцев до своего рождения.
Теперь мне бы узнать для каких программистких целей мне лучше его использовать?
P.S. KIV, спасибо за нормальный ответ.
hardcase'у таки тоже спасибо.
Например, Java можно запустить и в Windows, и в Linux, и Mac OS и на многих других системах. Причём Sun сама позаботилась о том, чтобы JVM были для всех распрастранённых ОС.
В .NET часто использую обращения к DLL. А это очень плохо. Кроссплатформенные на уровне бинарников приложения не должны знать ни про WinAPI, ни про POSIX, ни ещё какие-либо архитектурно спецефичные возможности. В идеале приложение просто не должно иметь возможность обратиться к функциям ОС напрямую. Лишь к ос-независимым прослойкам. Насколько мне известно у MS была попытка выпустить свою JVM, в которой предоставлялись дополнительные виндоспецифичные функции. Как можно считать кроссплатформенным язык где имется (и самое главное - часто используется) возможность вызова DLL? Проект Mono ещё сыроват. К тому же это получается почти то же, что и Wine - ведь придётся имитировать USER32.DLL и прочие библиотеки о которых Linux и прочие системы понятия не имеют.
P. S. Теме место в "Общалке"...
И где теперь Sun? ;)
Впрочем, .NET была и остается системой для программирования под Windows, в отличие от Mono. Под кроссплатформенностью .NET понимают двоичную переносимость сборок, которую обеспечивает международный стандарт CLR (форматы, базовый АПИ и прочее, а вот WinForms кстати не входит в этот стандарт).
Так никто ведь не заставляет PInvok-ать. ;)
Если целевая платформа - Windows, то зачем заботиться о переносимости? Если планируется несколько платформ, за зачем тогда использовать платформенно-зависимый API?
Хм... в Java есть возможность вызвать нативный код на C (к сожалению не помню как это называлось).
P.S. KIV, спасибо за нормальный ответ.
hardcase'у таки тоже спасибо.
Вы таки хотите получить ответ, осмыслив который придете к мысли о том, что .NET вам не нужен? Или вы предлагаете процитировать рекламные слоганы с http://www.microsoft.com/net/ (там кстати наглядная картинка есть)?
Я хочу получить ответ, а нужен ли он мне, как разработчику ПО? Стоит ли мне заморачиваться на его изучение, чтобы потом иметь с этого какой-то неведомый %$@нный профит?
Я тоже не понимаю этой платформы.Почему бы тогда функциональным программированием не заняться?
Такое чувство, что афтора фашисты в Бухенвальде заставляют .NET изучать. Очередной "унылый гот"(ц)
"Унылый гот"????? БУГАГА!!!! Это про меня, чтоли? Ты прям Петросян!
ИМХО, Теме место в FAQ раздела.
Напрашивается ассоциативный ряд:
Зачем изучать Java?
Зачем изучать C++?
Зачем изучать русский язык?
Зачем вообще учиться?
И как вообще все эти знания позволят получать "неведомый %$@нный профит"?
Как следствие, полученное умение даст возможность устроиться на хорошую работу и получать "неведомый %$@нный профит" в виде денег
Афтар, тебя что, правда заставляют? Я угадал? По работе? Беги от них - они идиоты. Я не шучу.
А если тебя просто терзают смутные сомненья "чем бы заняться?", а друзья/приятели насоветовали .NET, но ты его в корне не понял, то всем пох на твои проблемы.
Помни, главное - это цель. Цель, как я понял - бабло. Цель верная. А язык/платформа/фреймворк - всего лишь средства. А ты сейчас ставишь средство выше цели - это основная ошибка.
Нет на работе меня не заставляют изучать эту херотень. И слава Б-гу!
Вот и я спрашиваю для каких целей? При каких условиях этот ваш точкаНет станет почти идеальным средством разработки?
Вот и я спрашиваю для каких целей? При каких условиях этот ваш точкаНет станет почти идеальным средством разработки?
Когда надо быстро, без всяких заморочек на особенности работы с железом/памятью и пр. решить задачу - написать аппликуху под винду.
Правда у меня появились другая пара вопросов:
1) Хотелось бы конкретизировать: В какой области программирования его лучше юзать? Построение клиент-серверных приложений, математические алгоритмы, проги для работы с железом et cetera
2)
»без всяких заморочек на особенности работы с железом/памятью
Сдаётся мне что так можно сказать и про средней руки проги на Делфи
Правда у меня появились другая пара вопросов:
1) Хотелось бы конкретизировать: В какой области программирования его лучше юзать? Построение клиент-серверных приложений, математические алгоритмы, проги для работы с железом et cetera
Во всех можно пользовать. Сама библиотека довольно удобно спроектирована. Единственное, что в неуправляемых языках мат. алгоритмы будут несколько быстрее работать (сборщик мусора мешаться не будет).
2)
Сдаётся мне что так можно сказать и про средней руки проги на Делфи
Дык дотнет это реинкарнация ВЦЛ-а от микрософта.
1. C/C++ - чтобы писать относительно быстрые приложения и даже с переносимостью на уровне исходников (если немного постараться)
2. Java - если скорость не критична, но важна переносимость на уровне бинарников (почти ничего специально для этого делать не придётся)
3. C# - если переносимость в любом виде (на уровне исходников или бинарников) не волнует, но хочется получить всякие плюшки ввиде сборщика мусора и богатого набора классов. Скорость несколько ниже, чем у C++, но должна быть выше, чем у Java (ведь код в самом конце перед запуском переводится в машинный)
Для любых задач подойдут первые два варианта. Но при желании (исходя из преимуществ и недостатков C#) можно выбрать и 3 вариант. Лично я бы его никогда использовать не стал, но...
2. Java - если скорость не критична, но важна переносимость на уровне бинарников (почти ничего специально для этого делать не придётся)
3. C# - если переносимость в любом виде (на уровне исходников или бинарников) не волнует, но хочется получить всякие плюшки ввиде сборщика мусора и богатого набора классов. Скорость несколько ниже, чем у C++, но должна быть выше, чем у Java (ведь код в самом конце перед запуском переводится в машинный)
Хочу разочаровать, но Java приложения во многих случаях рвут по производительности аналогичный софт на C/C++. А вот с .NET дела похуже, так как платформа значительно моложе оптимизатор там не такой продвинутый.
Это не моя вина, господа, что мой простой и наивный вопрос смог вызвать у вас такое бурление говн. Никто никого троллить не собирался! Так-то!
Post Scriptum: Всем ответившим спасибо. Что хотел узнать я узнал.
Заинтриговал. Можешь привести примеры?
Афтар, никакого бурления нет. Такие темы создают либо троли, либо люди с альтернативным развитием.
В .NET часто использую обращения к DLL. А это очень плохо.
Ок. Не используй :).
Кроссплатформенные на уровне бинарников приложения не должны знать ни про WinAPI, ни про POSIX, ни ещё какие-либо архитектурно спецефичные возможности. В идеале приложение просто не должно иметь возможность обратиться к функциям ОС напрямую. Лишь к ос-независимым прослойкам. Насколько мне известно у MS была попытка выпустить свою JVM, в которой предоставлялись дополнительные виндоспецифичные функции. Как можно считать кроссплатформенным язык где имется (и самое главное - часто используется) возможность вызова DLL? Проект Mono ещё сыроват. К тому же это получается почти то же, что и Wine - ведь придётся имитировать USER32.DLL и прочие библиотеки о которых Linux и прочие системы понятия не имеют.
P. S. Теме место в "Общалке"...
Так и внутри JVM и стандатной библиотеки Java используются вызовы Dll, как во твоему иначе например можно реализовать работу с потоками, IO и прочим :)
Да и мне случалось использовать JNI самому (правда, только один раз, и я больше постараюсь никогда без крайней необходимости больше не прибегать к этому).
Факт, что с развитием платформ для управляемого кода и доступных библиотек под него, необходисть самому использовать JNI все уменьшается. И это радует.
Правда у меня появились другая пара вопросов:
1) Хотелось бы конкретизировать: В какой области программирования его лучше юзать? Построение клиент-серверных приложений, математические алгоритмы, проги для работы с железом et cetera
2)
»без всяких заморочек на особенности работы с железом/памятью
Сдаётся мне что так можно сказать и про средней руки проги на Делфи
Нет!
Суть в другом.
.NET -это платформа управляемого кода. CLR, CTS, и прочее. Это MSIL, слой совместимости множества языков, от C# до F/R#, IronPython, и еще многих. Это интеграция с MSSQL, и еще многими виндовыми платфорами.
Сравнивать это с формочками на дельфи - смешно.
Че тут интриговать то. Ощущение, что в теме кроме Хардкейза и меня никто не ковырял никогда потроха управляемых сред, хотя бы концепты.
Фундаментальное обоснование - JIT компилятор позволяют генерить машинный код для часто вызываемых метотов в тот момент, когда уже известны аппаратные характеристики хоста. Конкретный тип процессора и его характеристики, в т.ч. размер кеша, конвееры и прочее, количество памяти и ее лейаут.
Статические компиляторы такой информации не имеют. И потому, приложение на С, реализующее какой-нибудь численный метод, скомпиленное под i386 generic arch, или просто скомпиленное обычным компилятором без ультраоптимизации (последний GCC, Intel CC), будет работать медленнее.
Писать пример маленький..мне лениво :( Простите меня пожалуйтса.
Теперь я понимаю, почему многие проги на Java стартуют по минуте.
Я же не код просил, а примеры приложений. Из твоей теории следует, что это какие-то серверные приложения. Для настольных программ это не слишком здорово. Придётся не выключать комп и не закрывать приложение, чтобы не чувствовать раздражения от долгого запуска.
Закрывать можно. Система кэширует скомпилированный код. В .NET статическую прекомпиляцию осуществляет ngen. Как правило, при инсталляции .NET приложений все сборки прогоняются через него.
Я не отриацл, что любая программа рано или поздно обращается к API. Просто в идеале не должно быть возможности обраться к API из программы напрямую. То есть у приложения, например, есть класс Window. Оно может его создать. Однако вызвать напрямую CreateWindowEx возможности быть не должно.
Вот и молодец, что не используешь. JNI используется не так уж и часто. А вот Pinvoke в .NET приложениях встречается с завидной регулярностью.
Я про .Net ничего плохого не говорю. Если не можете привести конкретных примеров, то я приведу. Правда будут не аналоги, а произвольные примеры.
Например, NetBeans, Eclipse - запускаются по минуте, тормозят. Понятно, что это монстры, но всё же. А больше известных настольных приложений на Java и не припомню. Вроде OpenOffice как-то с ней связан был, и тоже тормозной.
С другой стороны Paint.Net - стартует быстро, работает без тормозов. Хотя, это и не монстр, конечно.
В теории то всё красиво, а на практике как-то так.
Я же не код просил, а примеры приложений. Из твоей теории следует, что это какие-то серверные приложения. Для настольных программ это не слишком здорово. Придётся не выключать комп и не закрывать приложение, чтобы не чувствовать раздражения от долгого запуска.
Следует различать клиентскую и серверную версии JVM. И понимать различие между ними, в том числе различие в приоритетах оптимизации.
А для клиентской существует, например, так называемый class data sharing, значительно уменьшающий время загрузки для мелких приложений.
А еще, посмотри, сколько времени стартует Visual Studio (написанная на .net / C++) с солюшеном в котором 10 тысяч классов, и сравни со временем старта Idea/ Eclipse :)
Ты имеешь в виду, что нативный код, сгенеренный JIT, дампится где-то? Поблизости от GAC или еще где? Если так, это разумная оптимизация.
В Java кешируются только внутреннее представление core library classes, тот самый class data sharing который я упоминал. Да и то, он работает по дефолту только на клиентской версии JVM.
А от решения кешировать скомпиленный нативный код отказались по двум соображениям, оба из которых мне не кажутся разумными:
1) Security caveats. (Как насчет хешей, ключей, trusted storages..etc)
2) Якобы нет смысла хранить скомпиленный неизвестно когда код, так как он мб быть уже "устаревшим" в плане оптимальности и лучше его перегенерить.
А вообще для серверной версии JVM суть проста -- лучше долгий старт сервера и потом более быстрая работа, чем быстрый старт. На десктопной версии - наоборот (часто, но не всегда).
Кстати, Когром. Предпочел бы ты старт IDE, который ты вряд ли делаешь чаще чем раз 5 в день, за 10 секунд, или старт старт в 1 минуту, и работу среды затем скажем, процентов на 10-15 быстрей?
Альтернативное не значит плохое!;)