@Green

Какой язык программирования в .NET является для вас основным?

0

@PB

Никакой, т. к. считаю что платформа .NET это очередная хрень МелкоМягких, которая не имея очевидных приемуществ, имеет очень много недостатков!

0

@Paulie

PB, готов выслушать все недостатки, в общем, хотелось бы с Вашей точки зрения услышать это в сравнении с PureBasic, которому Вы поклоняетесь, если несложно, то вкратце опишите и обратную сторону медали, т.е. недостатки пб в сравнении с .нет...

0

@PB

Приведу только три основных недостатка.

1. Проги для своей работы требуют .NET, который пока установлен не на всех компах! Посмотрите сколько есть тем на форуме, в которых обсуждает работа прог без .NET Framework, даже предлагалось запихивать часть Framework в исполняемый файл, отчего его размер становился больше 15 МБ. Значит это не мной выдуманая проблема - она реально существует!

2. Как правило .NET приложения работают гораздо медленее native кода! А раз так, то зачем сознательно замедлять проги? Ведь МелкоМягким только это и надо, чтобы покупали компы помощьнее. Ради этого они .NET распространяют бесплатно, а бесплатный сыр сами знаете где! МелкоМягкие утверждают что проги на .NET платформе кроссплатформенны, но на деле это не так! Проект mono невсчёт, он не очень стабильно работает. А для мака альтернативы .NETа вроде вообще нет, так где-же обещаная кроссплатформенность?

3. Для доступа к API нужно извращятся, ручками вызывая функции прямо с User32.dll, kernel32.dll и др

PS.

#Мессир, а теперь вы напишите про достоинства .NETа

Добавлено через 10 минут
Да, ещё, попробуйте запустить .NET приложение в Win98.
Я не уверен что туда вообще .NET Framework установить можно, а про Win95 я вообще молчу.

0

oxotnik

доводы высосаны из пальца.
1. Сравните с явовским приложениями - тоже нужна ВМ. Возьмите любую виндовую прогу и запустите не под виндой - нужны виндовые библиотеки и АПИ
2. По скорости работы - есть куча тестов и если где то уступает то не значительно и за счет удобства разработки.
3. в дотнете есть практически все, чтобы не использовать АПИ, да и не большой это геморой

ЗЫ: вы бы еще .NET под досом пускали

0

@Vladiator

Можно было Delphi.NET в опрос добавить

Добавлено через 3 минуты
2 минуса, которые я сам испытал с .NET:

• компонентов не так много, как в VCL
• идёт не на всех компах

кроме быстрой работы плюсов пока не замечаю

0

@Mecid

1.дотнет есть почти у всех,для меня хоть и основной язык JAVA,но дотнет имеется и ставил я его не ручками,он по уморлчанию в СП3,я уже не говорю про висту и семерку которые основаны на дотнете.
2.сейчас Виртуальные Машины допилины так что почти не уступают нативным,да и компы сейчас не слабые.
3.у дотнета есть своя библиотека со всем необходимым.
теперь о плюсах
1.быстрая разработка
для меня это является самым главным плюсом

0

@PB

Его нет по умолчанию в чистой WinXP SP3!
Только в некоторых левых сборках!

0

@Mecid

тем более.чаще всего ставят эти левые сборки

0

@IT_Exp

PB,
2. Как правило .NET приложения работают гораздо медленее native кода!
в аналогичной холиварной теме я уже предлагал всем желающим сравнить скорость
программа на c# прокачала 50 гигов памяти за 1-2 минуты, и сколько-то там миллионов совпадений паттерна для IP-адреса в 100-мегабайтном файле за ~10секунд.

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

2

@homich77

ото ведать некоторые просто покричать любят!

0

@Paulie

PB, сорри, программировал в 1С. Почему-то написанный код не работает без 1С, странно, надо будет разобраться на досуге, ну да ладно, теперь о главном:

Преимущества .НЕТ:
1. Достаточно быстрая разработка приложений
2. Скорость работы может на 5-10% медленнее (хотя смотря какие сценарии), но разработа этих сценариев проще, плюс внешний вид програмнмого обеспечения - а ну ка на WinAPI анимацию сделать с прозрачностью и всё такое?
3. Технология WPF - достаточно мощная штука, можно разрабатывать красивые мультимедийные, и не только, приложения, хотя пока не так уж много компонентов, подождём
4. Программы достаточно маленькие по объёму (один раз скачал .НЕТ фрэймворк и всё, пользуйся на здоровье). Скажем в Qt.... вспомним VLC плеер, вроде как там 19 метров исполняемый файл?
В общем всё что связано с разработкой ПО для широкой публики, технология .NET очень упрощает жизнь - это и приятный интерфейс, это хорошая скорость работы, это и простота разработки (как уже было сказано), а для критических областей программы можно и прикрутить библиотеки user32.dll и прочие. В конце-концов на это времени уйдёт гораздо меньше, чем, скажем, на Win32API описывать создание окна и генерации в нём элементов управления.

Что мне в .НЕТ не нравится:
1. Среда разработки достаточно стабильная, мощная, но жутко тугодумная (на несильных машинах), скажем при работе в 1С (2-3 окна открытых), открытом MSDN локально, и приложении Lotus notes (о нём скажу отдельно) - работать в визуал студио непросто (тача пнеь е2ххх на 2 ггц, и 1 гиг ОЗУ, виста). Хотя этот недостаток можно сгладить блокнотом и всё такое, но теряется Intellisence и все вкусности подобные ему.
2. читал, что проще получить исходный код приложения, дизассемблировав его из байт кода, в который кодируется приложенеи .NET - сам не проверял.
3. Писал приложение для поиска файлов на WinAPI и C#, ну проще, конечно, на C# - но по производительности проигрывала слегка, плюс на том компьютере не стоит .NET Framework, и поставить его туда не было возможности.
Больше недостатков мне сейчас не вытянуть из себя, умственный спад после работы.

Насчёт Lotus Notes - написан, как я понимаю, на Ява, НО как он тормозит машину - это не передать словами.... Больше не держу его открытым, иначе тачка под конец дня шевелится, как ХР на первом пне - Java - не экономит ресурсы...

0

Evg

Если уж возникло желание поворошить прошлое, то можно ещё вспомнить следующие моменты:

• Тебе вполне конкретно пояснили, почему такой пример не является показательным, а так же пояснили, как должен выглядеть показательный пример. Соответствующий код ты так и не написал
• На конкретно поставленный вопрос типа "а нахера нужно было городить огород и создавать виртуальную платформу, вместо того, чтобы сделать это в native-кодах" так никто и не ответил

Это так, не претензия, а лирическое отступление

Добавлено через 3 минуты
Ты уверен, что все эти удобства - это свойства платформы .NET, а не среды разработки?

0

@Paulie

Всё здесь взаимосвязано, не было бы одного, не было бы другого Скажем анимация и всё такое - реализовано в .NET, а позволяет это всё собрать, скомпоновать, одеть и запустить - среда разработки и компилятор.

0

Evg

Говорить, что анимация реализована в .NET всё равно, что говорить, что анимация реализована на i386. А взаимосвязь тут простая: МС захотели .NET, вот и среды разработки под него делают удобнее, чтобы народ начал хотеть этот .NET

А вообще, после обмозговывания у меня получилось примерно следующее. Переносимость в теории на все платформы должна быть, реально с этим они скорее всего обо$рались, но переносимость между разными версиями виндов и на разных процессорах - судя по всему работает. При этом native код, собранный под 32битную платформу (i386), работает и на 64битной (x86_64), но скорость исполнения кода ниде, чем если бы приложение было откомпилено под x86_64. Но если его откомпилять под x86_64, то оно попросту не будет работать на i386. С концепцией .NET эта проблема отпадает, ибо всё это разруливается на уровне реализации .NET под платформу. То же самое и между версиями винды: больше не надо гемороиться с тем, чтобы программа работала под всеми версиями - всё сокрыто внутри реализации framework'а под конкретную версию винды.

Этим я сам себе ответил на вопрос, а почему нельзя было это делать в native кодах. Можно было, но получилось бы менее эффективно. Правда всё равно оказалось сделано через $опу: и разные версии framework'ов, и миллион упомянутых проблем с их установкой. Можно сколько угодно говорить, что в висте и семёрке все уже сразу встроено, но с вистой МС уже обо$рались, посмотрим, что получится с семёркой. Насколько я понимаю, пока XP/SP2 наиболее распространённая версия. Если в домашних условиях снести XP и поставить семёрку для большинства раз плюнуть (к тому же ещё и ворованные версии), то для больших организаций это дело стОит большого гемороя и больших денег. Если народ не захочет переходить на семёрку, то в очередной раз план завхата мирового господства отодвинется на неопределённый срок.

Ну и к тому же .NET - это не технология будущего, это просто концепция виндов будущего. В то, что всё это будет нормально работать и на других архитектурах - что-то в это верится с трудом. Хотя идея в принципе хорошая. Ну а поскольку идея является новой, то к ней очень хорошо притесалась концепция взаимодействия кодов, написанных на разных языках. Эта идея реализуется и в native-кодах, но там сразу же возникнет миллион вопросов по совместимости со старым (а для ,net этой проблемы нет, ибо это новая идея). Ну и все языки под .NET являются более строгими и не допускают фривольностей, как Си и Си++

0

@Green

Следим за темой. Опрос по языкам программирования .NET.
Мысли о преимуществах/недостатках платформы высказываем здесь:
Что такое NET FRAMEWORK ???

0

Evg

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

0

@M128K145

вижу кто-то проголосовал за С++. ИМХО, это извращение

0

Evg

При дальнейшем размышлении получилось вот ещё что.

На языке Си, например, можно написать кроссплатформенное приложение. В 70-80х годах, пока практически везде работа шла в терминале, это было вполне приемлимо и исходники действительно хорошо переносились на разные платформы. Т.е. получается так, что программист пишет программу, и всё это делается в предположении, что на разных архитектурах уже есть реализованные компиляторы, библиотеки и прочее

Затем начали появляться различные графические оболочки, звук и прочие прибабахи и работа с графикой на разных ОС начала сильно разъезжаться. Переносимый код стало писать слишком сложно, потому что, например, работа с тем же самым звуком на разных ОС делается совершенно по разному. Поэтому начали появляться кроссплатформенные графические и звуковые библиотеки и прочие воспомогательные средства. И получается при этом так, что каждую библиотеку нужно адаптировать к куче платформ. При появлении новой платформы надо адаптировать кучу библиотек под эти платформы. Переносимость формально остаётся, но реально на практике сопрягается с большим количеством трудностей.

Идея JAVA и .NET состоит в том, что создаётся некоторая виртуальная платформа, с жёстко зафиксированными программными соглашениями. Далее компилируется текст на языке в код этой виртуальной платформы и получается таким образом некий бинарный файл. На каждой архитектуре пишется интерпретатор (как это было с JAVA) или JIT - just in time compiler (который начал позже появляться в java и изначально было в .net). Далее этот код интерпретируется (ну или делается run-time компиляция в native код).

Таким образом получается следующее. При написании преносимого кода на Си надо реализовывать большое количество переносимых библиотек. При работе через виртуальную платформу необходимо только реализовывать интерпретатор (или JIT-компилятор) на каждую архитектуру. А вот с библиотеками этого делать не надо. Библиотеки пишут один раз под виртуальную платформу и дальше на каждой реальной платформе исполняются.

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

Несколькими постами выше я уже писал, что такой подход имеет дополнительный бонус в виде того, что на новый процессор в семействе процессоров можно иметь тот же самый код программы, но который будет работать быстрее за счёт того, что код не исполняется непосредственно, а интерпретируется (или jit-компилируется)

1

@RazorQ

Проголосовал за C# - он специально для этого создавался. Платформа net очень грубо врезается в С++. Это настоящие извращение программировать под нет на Си++.

0