c# vs. vb.net

[tortilla]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?

Spasibo.

[A. Fig Lee]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?

Spasibo.

Ну если нет аргументов - может ето нецелесообразно?

[vovap]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?

Spasibo.

Реальных аргументов нет - так как С# и VB.NET совершенно аналогичны. Ну а придумать - это другое дело.

[trialex]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?

Spasibo.

Welcome to the club!
Мне нужно сделать точно такое же обоснование
Правда нам не ГУЙ писать, так что тут полегче. Аргументы следующие:
более чистый и читабельный код, наличие using/unsafe, блоков { } в любом месте. Стандартизация ECMA. То, что С# придуман вместе с .NET и за ним будущее!
Кроме того, MS позиционирует C# как RAD, обеспечивающий полный контроль над кодом, на работе есть линк на статью. Да и вообще, VB .NET просто ugly

[IA72]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?
Spasibo.

Собственно, аргументов может быть несколько разноплановых.
В зависимости от. Нетехнический, к примеру - C# любимый язык МS на сегодня и они его будут развивать и дальше, а вот VB.NET это теперь пасынок и пропащая душа.
Полутехнический - использования знакомого с VB языка и синтаксиса может привести к нежелательным корелляциям с дремучим VB стилем и значительно ухудшит качество портированного кода. Большая часть толковых книг по .NET использует С#, то есть знать его все равно надо.
Технический - если требуется unsafe code, в VB.NET его нет - а вероятность его использования вероятна (давеча пришлось вспоминать GetWindowsDC к примеру )
Так же там нет перегрузки операторов и xml комментариев.
И не будет inline функций и темплейтов.

[KRV]

Мне надо аргументированно доказать, что перевод нашего существующего в vb6 application на .NET целеcообразно делать сразу C# а не возиться с VB.NET . Но вот где бы аргументов набрать? Any idea?

Spasibo.

Платформа-то одна и та же. То есть все отличия носят главным образом синтаксический характер. Есть особенности при реализации абстрактных классов, полиморфизме, при работе с не .NET библиотеками, компонентами. Там - сям по мелочи...
Отталкиваться надо не от этого. Если тим писал на VB - значит VB.NET будет им лучше. Не надо людей учить новому синтаксису, переходный этап будет попроще. Если писали на C++ или жабе - лучше C#... Мелкософтовцы вроде так ведь и задумали, чтобы сразу и всех к себе заманить - сделали библиотеку классов с интерпретатором псевдокода, а чем этот псевдокод генерится - один фиг.
Мой совет - бросьте это гнилое дело. На чем скажут - на том напишете. Ваш опыт от этого особо не пострадает. Базовые классы платформы изучите в любом случае, среда разработки - все равно одна на все семейство .NET, а то в какую синтаксическую обертку заворачивать классы - вопрос эстетики в основном...

[tortilla]

Team- ето нас трое, один- принимающии решения- совершенно необразованныи самоучка. Все написано на vb.6, a я преследую свои шкурные интересы- что наиболее перспективно с точки зрения будущего для меня. Мне лучше бы начать работать в C# если за ним будущее. Может быть он работает быстрее, чем vb.net?

[vovap]

Team- ето нас трое, один- принимающии решения- совершенно необразованныи самоучка. Все написано на vb.6, a я преследую свои шкурные интересы- что наиболее перспективно с точки зрения будущего для меня. Мне лучше бы начать работать в C# если за ним будущее. Может быть он работает быстрее, чем vb.net?

Нет, не быстрее. Это вообще вопрос бессмысленный - "он" - не работает. И то и другое переводится в код на языке промежуточного уровня а уж оттуда компилируется.
Если же у Вас еще и нет опыта работы с C#, то я бы вообще очень сильно подумал, прежде чем проталкивать такое решение. Когда за проектом стоит реальная система, находящаяся в бизнесе, реальные сроки и деньги, то вещи вообще смотрятся существенно иначе. И часто оказыватся, что изящество программирования и вкусы далеко не на первом месте. Вот станет Ваш проект срывать сроки, полезут баги - посмотрят тогда на Вас и спросят - а кто говорил, C# лучше? И шо Вы будите отвечать?
А в реальности, конечно, если проект - на VB и команда работает только на VB без опыта С++ или Java - то тащить его на С# можно только если деньги и время - не факторы. Так что подумайте - шишки-то на Вашу голову упадут.
С точки зрения же просто "шкурных" интересов и перехода на NET человека с опытом VB лучше VB.NET - позволит сконцентрироваться на реально новых возможностях а не борьбе с новым синтаксисом. И важный шаг в понимании NET платформы (это я совершенно серьезно) - отказ от глупостей, что между VB.Net и C# есть существенная разница.

[IA72]

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

Слегка быстрее, ибо трансляторы в il разные.

С точки зрения же просто "шкурных" интересов и перехода на NET человека с опытом VB лучше VB.NET - позволит сконцентрироваться на реально новых возможностях а не борьбе с новым синтаксисом. И важный шаг в понимании NET платформы (это я совершенно серьезно) - отказ от глупостей, что между VB.Net и C# есть существенная разница.

Я как раз считаю наоборот - c# лучше тем для ex-VB, что не несет в себе груза прошлого, хотя бы и синтаксис. Слишком сильны отличия от VB6, так что проще и полезнее начать с чистого листа. К тому же разница между vb.net & c# есть, как я выше написал, использование же unsafe code я отношу к существенным различиям.

[vovap]

Слегка быстрее, ибо трансляторы в il разные.

Конечно, теоретически они могут ненерировать il код разного качества. Но вот, если честно, на чем основано Ваше мнение, что "Слегка быстрее"? Вы проверяли? Видели данные сравнений? Каких?
Я бы взялся утверждать, что достаточно простой аналогичный код трансляторы откомпилируют одинаково, а что до более сложного - то как можно будет говорить о его аналогичности? Это уже будет зависеть от эффективности реализации на данном языке. Согласитесь, что это не что-то, что можно будет заметить в реальной жизни. Я уж не говорю о том, что поцентов 80% разговоров о скорости компиляторов и языков - вообще мульки и быстродействие системы обычно практически полностью зависит от программирования.

Я как раз считаю наоборот - c# лучше тем для ex-VB, что не несет в себе груза прошлого, хотя бы и синтаксис.

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

К тому же разница между vb.net & c# есть, как я выше написал, использование же unsafe code я отношу к существенным различиям.

Нету разници. И в использовании unsafe code в том числе
http://www.dotnetcoders.com/web/learnin ... dcode.aspx

The syntax in VB.NET is similiar to that in Visual Basic 6. To use an API function, you have to declare it prior to invoking it, using the following syntax:

Declare StringConversionType (Function | Sub) MethodName Lib "DllName" ([Args]) As ReturnType

Вы не обижайтесь, но это пример именно того непонимания, о котором я говрил. Если il и платформа чего могут - значит могут оба языка.
Конечно, ребята из Microsoft могли бы не включить каких-то возможностей, скажем, в VB.NET, но это противоречило бы идеологии системы и они, разумеется, этого не делали. По крайней мере по отношению к чему-то существенному.
Мелкие же различия, конечно есть. Есть, кстати, и вещи, которые VB делает, а C# - нет (кажется - генерирования нескольких Dll на одну ассембли). Но это все такие детали, что говорить о них в подобной ситуации - не серьезно

[voron999]

я тоже думаю что C# vs. VB.NET - спор на пустом месте. Особенно когда VS.NET 1.1 уже вышел. Самое главное - знать систему .NET, a syntax не так важен. Все к этому идет.

А персонал'ный вкус - другое дело. Будучи манагером, я бы не стал платит' бол'ше за C#, чем за VB.NET. Не за что. C++ - другое дело, но тол'ко за подходящих случаях.

Кстати последняя версия МС Оффис (или что-то из этой серии) написана на VB.NET.

Единственно что я бы советовал - ВСЕ надо делат' через .NET классы, надо избегат' старых VB'шных функций которые там оставили. Когда все делается через .NET (not CStr(string) but Convert.ToString(string), for example), то потом остал'ное не так важно.

Heck, why don't you propose COBOL.NET? Different syntax, same output.

[IA72]

Слегка быстрее, ибо трансляторы в il разные.

Конечно, теоретически они могут ненерировать il код разного качества. Но вот, если честно, на чем основано Ваше мнение, что "Слегка быстрее"? Вы проверяли? Видели данные сравнений? Каких?

google ваш друг. Сам не мерил, но читал. Не думаю, что разница существенна, но утверждать, что ее нет и не может быть - это ошибка и непонимание.
Ибо перевод кода в нативный осуществляется в два этапа - language-->il и il--> native.

Я уж не говорю о том, что поцентов 80% разговоров о скорости компиляторов и языков - вообще мульки и быстродействие системы обычно практически полностью зависит от программирования.

Да, но речь о принципе.

Я как раз считаю наоборот - c# лучше тем для ex-VB, что не несет в себе груза прошлого, хотя бы и синтаксис.

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

Не согласен - синтаксис c# прост, но изучение его поможет писать правильно, а не слепо копировать старый код с VB

К тому же разница между vb.net & c# есть, как я выше написал, использование же unsafe code я отношу к существенным различиям.

Нету разници. И в использовании unsafe code в том числе
http://www.dotnetcoders.com/web/learnin ... dcode.aspx

The syntax in VB.NET is similiar to that in Visual Basic 6. To use an API function, you have to declare it prior to invoking it, using the following syntax:

Declare StringConversionType (Function | Sub) MethodName Lib "DllName" ([Args]) As ReturnType

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

Я не обижаюсь - это вы не понимаете. Погуглите keyword unsafe и перестаньте говорить глупости.
Что касается "если Il" поддерживает, то это тем более ерунда, ибо язык не обязательно должен (и так и происходит) поддерживать фичи .net runtime

Конечно, ребята из Microsoft могли бы не включить каких-то возможностей, скажем, в VB.NET, но это противоречило бы идеологии системы и они, разумеется, этого не делали. По крайней мере по отношению к чему-то существенному.

Могли бы и делали. Ибо старались облегчить горемыкам с VB переход,
чего стоит история с boolean.

Мелкие же различия, конечно есть. Есть, кстати, и вещи, которые VB делает, а C# - нет (кажется - генерирования нескольких Dll на одну ассембли). Но это все такие детали, что говорить о них в подобной ситуации - не серьезно

Нифига себе, несерьезно. У VB есть optional parameters, попробуйте с Excel поработать без них.

[trialex]

Мелкие же различия, конечно есть. Есть, кстати, и вещи, которые VB делает, а C# - нет (кажется - генерирования нескольких Dll на одну ассембли). Но это все такие детали, что говорить о них в подобной ситуации - не серьезно

Нифига себе, несерьезно. У VB есть optional parameters, попробуйте с Excel поработать без них.

Вот-вот, так и будут на VB .NET автоматицацию MS Office писать
Кроме того, params object[] list вполне себе optional parameters, да и Missing.Value никто не отменял

[IA72]

Мелкие же различия, конечно есть. Есть, кстати, и вещи, которые VB делает, а C# - нет (кажется - генерирования нескольких Dll на одну ассембли). Но это все такие детали, что говорить о них в подобной ситуации - не серьезно

Нифига себе, несерьезно. У VB есть optional parameters, попробуйте с Excel поработать без них.

Вот-вот, так и будут на VB .NET автоматицацию MS Office писать
Кроме того, params object[] list вполне себе optional parameters, да и Missing.Value никто не отменял

для того, что бы использовать params надо, что бы функция была с ними объявлена. Увы. А missing.Value...
Так, блин, и пишем.
object weDontNeedThisShit = Missing.Value;
Excel.DoSomething(ref something, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit)

[vovap]

google ваш друг. Сам не мерил, но читал. Не думаю, что разница существенна, но утверждать, что ее нет и не может быть - это ошибка и непонимание.
Ибо перевод кода в нативный осуществляется в два этапа - language-->il и il--> native.

Я тоже читал Только обоснование этого утверждение было такое же как у Вас Кроме общей идей, что С код должен быть быстрее других конкретных данных я не видел. И я не говорю, что не может быть разници. Я ж писал - теоретически, может. Ну, скажем, если группа делавшая VB прекомпилятор существенно слабее группы делавшей С# прекомпилятор. Только я в это не верю. Microsoft достаточно серьезная фирма для этого. И никто подобного пока не показал.

Да, но речь о принципе.

Да не о принципе, а о разработке конкретного проекта. Мы можем тут месяц сидеть и выискивать различия, спорить о их значении. А для проекта в реальной жизни разница есть? Нет. Тогда зачем дурью маяться?

Не согласен - синтаксис c# прост, но изучение его поможет писать правильно, а не слепо копировать старый код с VB

Это прекрасно в теории - "писать правильно, а не слепо копировать". А когда у Вас здоровый проект и надо его портировать в заданные сроки - очень может оказаться, что все время и усилия уйдут на то, чтобы просто переписать его в новом синтаксисе. И ни до какого "правильно" просто дело не дойдет. Мой бывший шеф любил рассказывать про проект, оторый он как-то видел на Java. Человек, его делавший, переводил его с COBOL и сам был из мира COBOL. Так вот он как на коболе и писал на Java. Синтаксис-то он освоил а вот дальше дело не пошло. Вы понимаете, когда время ограничено, его можно потратить только один раз - или чтобы переписать все строчки, или чтобы разобраться со структурой.
Я ж говорю - ели время - не фактор -тогда дело другое.

Я не обижаюсь - это вы не понимаете. Погуглите keyword unsafe и перестаньте говорить глупости.

А, значит Вы работу с поинтерами наружу имеете в виду. Но работа с понтерами - это нечто, противоречащее идеологии NET. Я не сомневаюсь, что в Microsoft были жаркии баталии, следует ли сохранять эту возможность C в C# и делать дырочку. И пошли на компромис чтобы "облегчить горемыкам с C переход" Пожертвовали структурной чистотой ради обратной совместимости - так же как и в лучаях с VB. В java, скажем, на такой компромис не пошли и ничего.
Кстати это ведь уступка этой самой реальности, а? Ведь все мы знаем, что так делать "не правельно". Правельно было бы переписать такие вещи заново, с чистого листа а?
Вот, кстати, очень толковый пост, суммаризирующий разницу между языками с очень полезными ссылками: http://www.mail-archive.com/bdotnet@gro ... 01543.html

Что касается "если Il" поддерживает, то это тем более ерунда, ибо язык не обязательно должен (и так и происходит) поддерживать фичи .net runtime

Да, разумеется. В общем случае язык не обязан поддерживать все фичи. Но за созданием VB.NET и С# стоит определенная идеология. Смысл которой - именно реализовать в обоих языках все основные возможности runtime. Я не возьмусь утвержать того же, скажем о COBOL.net

Могли бы и делали. Ибо старались облегчить горемыкам с VB переход,
чего стоит история с boolean.

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

[Gennadiy]

Нифига себе, несерьезно. У VB есть optional parameters, попробуйте с Excel поработать без них.

Вот-вот, так и будут на VB .NET автоматицацию MS Office писать
Кроме того, params object[] list вполне себе optional parameters, да и Missing.Value никто не отменял

для того, что бы использовать params надо, что бы функция была с ними объявлена. Увы. А missing.Value...
Так, блин, и пишем.
object weDontNeedThisShit = Missing.Value;
Excel.DoSomething(ref something, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit, ref weDontNeedThisShit)

Мало того, Missing.Value не поможет если default параметр был типизованый и имел значение по умолчанию отличное от 0/null/empty.

[trialex]

Мало того, Missing.Value не поможет если default параметр был типизованый и имел значение по умолчанию отличное от 0/null/empty.

Тогда ты знаешь, что нужно поставить "по-умолчанию". Прелесть C# именно в том, что все под контролем. Вот поэтому-то все эти optional parameters - зло. В VB не было раньше нормального function overloading, вот и извращались, как могли.

[leprechaun]

There's a lot of stuff on this matter at builder.com:

http://builder.com.com/5100-6373-1027686.html
http://builder.com.com/5100-6373-1045811.html
http://builder.com.com/5100-6387-1053708.html
http://builder.com.com/5100-6373-1049896.html

And it suggests that C# seems to be the better choice even if you're coming from the VB flock.

[tortilla]

There's a lot of stuff on this matter at builder.com:

http://builder.com.com/5100-6373-1027686.html
http://builder.com.com/5100-6373-1045811.html
http://builder.com.com/5100-6387-1053708.html
http://builder.com.com/5100-6373-1049896.html

And it suggests that C# seems to be the better choice even if you're coming from the VB flock.

Thanks,
i will read this over.