#48 Судя по отзывам моих знакомых, чтобы приложение все-таки нормально заработало под Моно, надо изначально писать с учетом этого. Во всех других случаях "чуть переделать клиент" превращается в "переписать полпрограммы". Поэтому в принципе многоплатформенность у .Net есть, но это не основная фича этой платформы.
Стал писать на C# только потому, что нужно было работать с мелкософтовскими продуктами через com. Не жалею, затянуло.
А насчет кроссплатформенности: сейчас популярны веб приложения, а хостингов с виндой уже хватает. Так что с моно в большинстве случаев можно не заморачиваться, ну или чуть переделать клиент, если нужно под линукс.
Жека jkff Кирпичев, Да нет, против IEnumerator ничего не имею, хотя деййсвительно его реализация не является чистой.
public static IEnumerable<int> inf()
{
int i = 0;
while(true)
{
Console.WriteLn("Side Effect");
yield return i++;
}
}
И пожалуйста, будет вам побочный эффект у каждого енамератора, но разумеется этого можно добиться и без использования yield.
Мои претензии не к тому. Мне не нравится метод, который может продолжить выполнение, уже после того, как вернул значение. А термин "чистый" я употребил не в плане отсутвия побочных эффектов, а в плане нарушения концепции функции.
#20 +1
Можно добавить, что java дешевле будет
А вообще, если уж тут затронули "фичи" синтаксиса C# советую прочитать следующую статью: //tinyurl.com/phvq7e
Николай, в общем, возьми код функции inf() и дизассемблируй его при помощи Lutz Reflector – увидишь, что никакими "лишними" побочными эффектами там и не пахнет.
Фактически, получается какой-то такой код:
class Inf : IEnumerable<int> {
private int i;
Inf() {i = 0;}
int Current {get {return i;}}
boolean MoveNext() {i++;}
}
IEnumerable<int> inf() {
return new Inf();
}
В таком случае я повторяю свой вопрос: правда ли, что ты против самой концепции IEnumerator как таковой? Ведь *любая* реализация IEnumerator – через yield ли, или не через yield – не является чистой.
Думаю, надо сравнивть по двум критериям: язык и платформа.
Я бы сформулировал так:
Java как язык – более рафинированный, более простой, логичный, менее разлапистый. Все фишки и тонкости, добавленные в C# с одной стороны упрощаю жизнь, с другой усложнят тем, что более сложны для понимания человеком (только не надо писать, что все просто или надо привыкнуть, дело в том, что все равно чем больше "фишек", тем больше напряжение мозга, хотя и подсознательное; даже аозвращение значения через параметр – уже весьма и весьма спорное решение).
Что же касается платформы, то Java – поистине кроссплатформенный (хотя надо знать тонкости и для Mac и для Linux и т.п.), в C# этим пока на серьезном уровне не пахнет.
> Это неверно. Это функция, возвращающая итератор, ничем не хуже любой другой функции, возвращающей итератор.
Может я конечно что-то путаю но разве такая функция(которая с yield) не начинает хранить в себе состояние? Например локальные переменные этой функции разве сбрасываются при "возвращении значения"? Тут же вообще должны возникать ленивые вычисления, которых в обычных функциях нет, так что это вовсе не обычная функция.
Александр Quyse Lert, да указывать вы можете и в шарпе, другой вопрос нет checked exceptions, но от них сознательно отказались. Вообще сейчас больше распространено мнение, что чекед ексепшинс не нужны
> Так yield return – это просто способ реализации IEnumerator<T>
Ну все есть реализация чегонибудь) Проблема в том, что если функция содержит yield return то она больше не функция, а некое новое синтаксическое явление. Для например Питона это не страшно ибо там функция есть объект, а объект может оказаться функцией) Но для джавы, где это не так, такая конструкция по сути являлась бы новой сущностью
Ну да… вспоминая JDBC можно слогласиться, не очень хорошо получается с close(), но честно скажу ввесьма редко с этим сталкиваюсь, и не то чтоб меня это сильно напрягало.
> yield return
Ну функция, которя возвращает несколько значений в разные моменты времени довольно суровая штука) По сути, генератор для ПП это новая сущность.
> и укладываются в массивы непосредственно, а не ссылками (и не могут быть null).
Ну да, зато копируются по значению и тем самым сьъедают свой выигрыш в производительности обратно. Хотя в целом против страктов ничего не имею, но особой радости от них тоже не испытываю.
Ну с null это известная проблема, она и в шарпе сплошь и рядом.
using – не согласен, что освобождение ресурсов – редкость.
И как ни крути, синтаксис освобождения ресурсов в джаве – жопа, тем более что какого-то хрена методы close() обычно бросают checked exceptions (ну и что с ними делать?). Освободить несколько, особенно взаимозависимых, ресурсов – синтаксическая каша.
yield return – а какие проблемы с его чистотой?
struct: во-первых, только с -XX:+DoEscapeAnalysis и только в последних версиях джавы; во-вторых, есть и другие отличия, влияющие на производительность, которых от джавы не дождешься: struct занимают меньше памяти за счет отсутствия (видимо) заголовка у объектов, и укладываются в массивы непосредственно, а не ссылками (и не могут быть null).
> reified generics. Сколько граблей из-за generic type erasure в Java!
Ну тут да, генерики в жаве убоги(( проще говоря их нет) Зато есть гарантии, что ход работы программы не зависит от параметризуемого типа, если это понимать в таком ключе, то все становится логично. Всю зависимую функциональность можно делегировать куда-нибудь – громоздко, но гораздо более наглядно.
> – using. Ну знаете ли, если вы не забываете написать юзинг, то не забывайте написать клозе. Да и вообще освобождение ресурсов в жаве – такая редкость, это вам не интерлопом с ком в C# заниматься
> – yield return.
Ну тут да, это полезная штука,пару раз сожалел что ее нет. Но вообще есть некоторые сомнения в ее чистоте для процедурного программирования.
> – делегаты.
нафиг плодить сущности. анонимные классы наше все! хотя тут конечно всплывает отсутвие в джаве нормального метапрограммирования, но это всеравно не повод.
> – struct
Ну авторы джавы клянутся и божатся, что потерь в производителности нет, все что можно выделить на стеке выделяется на стеке и так.
Не согласен, что все приведенные мною особенности шарпа – рюшечки, усложняющие язык. Как минимум, нижеприведенные фичи его, наоборот, упрощают и делают более надежным, удобным, отлаживаемым:
- reified generics. Сколько граблей из-за generic type erasure в Java!
- using. Сколько утечек ресурсов в программах на Java из-за того, что приходится писать грязный, уродливый, повторяющийся и почти не абстрагируемый код для освобождения ресурсов!
- yield return. Как трудно на Java писать сколько-нибудь сложные итераторы из-за отсутствия подобного интуитивного и удобнейшего средства!
- делегаты. Сколько красивых приемов программирования, будучи переведенными на Java, превращаются в грязное месиво из анонимных классов!
- struct: практически нисколько не усложняют язык, однако предоставляют улучшенные возможности для взаимодействия с внешним миром и оптимизации производительности.
Остальное, возможно, можно и отнести к рюшечкам.
Java гораздо более простой и чистый язык. Да в нем нет всяких рюшечек,рюшечки шарпа на мой взгляд часто лишь ухудшают читаемость и отлаживаемость кода, вспомнить хотяб Explicit Interface Implementation.
Я за джаву.
Еще к джаве есть много бесплатных офигенных IDE, которые напишут все за вас)
Согласен. Как язык C#, естественно, развитие Java-языка. Но .Net платформа менее гибка чем Java.
Обосновываю (имею ввиду платформу):
Java-таки нативно работает в большинстве ОС
Java легко расширяется
Java интегрируется со всем что угодно, а не только с продуктами от MS
Java охватывает embedded устройства
Java открыта (таки это свершилось)
Java, как платформа, компактнее
Java имеет транспорты и универсальные коннекторы к "чужим" компонентам
Основные библиотеки Java мультиплатформенны и не прибиты гвоздями к конкретной ОС.
Поймите мою точку зрения, мне нравится C#, но из-за того что он прибит гвоздями к .Net, а .Net впаян в Windows, его применение для меня резко ограничено. Java в этом плане удобнее. Написал один раз и не паришься какие у тебя целевые машины и сервера.
#11. Мотивирую:
Фундаментальные (неэмулируемые или очень трудно эмулируемые) преимущества:
- В C# есть reified generics
- В C# есть yield return
- В C# есть struct
- В C# есть unsafe блоки и указатели на крайний случай
- В C# есть expression trees
Синтаксические (эмулируемые) преимущества:
- В C# есть using
- В C# есть out и ref параметры
- В C# есть замыкания с приличным синтаксисом (делегаты и собственно лямбды)
- В C# есть events
- В C# есть много другого удобного синтаксиса: collection и object initializers, local type inference
- В C# есть LINQ
Хотя тут не обсуждение что лучше. Тут доказывают, что если к протвиню от Electrolux плиты примотать проволоку, да дырочек насверлить, то его, наверное, можно будет подвесить на треногу и попытаться сварить в нём суп (только через каждые 5 секунд вода будет выливаться).
"вы всё ещё завариваете чай в коптильне установленой на пароварку? ммм.. мы вызываем санитаров к вам."
Очень похоже на попытки перетащить что-нибудь .Net-ое на Mono.
P.S: А котелок-то подходит для того чтобы его в духовку поставить!!
#11 -обоснования и ссылки в студию. "Правильность" – очень субъективно, хотя не лишено логики, т.к. c# делался по образу и подобию Java с максимальной на неё оглядкой : //ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B...
(1) что лучше чайник или кастрюля?
(2) лучше всего протвинь!
(3) и как ты на треноге протвинь крепить собираешься? лучше походного котелка ничего быть не может!
(4) чёго вы все несёте ни в котелке ни на протвине коптить не получится, надо нормальную rкоптильню.
<…>
вы всё ещё завариваете чай в коптильне установленой на пароварку? ммм.. мы вызываем санитаров к вам.
#7 Как язык для CLR может быть кроссплатформенным? Поясните ваше высказывание. Естественно, в данном треде кроссплатформенностью считается возможность запуска в различных ОС.
Надо бы знать, что Mono – это open source проект, соответственно, MS на него плевать и каждый чих в спецификации платформы .Net и основных #-языков заставляют переписывать огромные участки кода проекта. Тем более на mono даже и не пахнет полноценной заменой _платформы_ .Net, не говоря уже о том, что C# и .Net вне Windows _бесполезны_. Hello world, написанный на C#, конечно запуститься, но любой энтрепрейс, особенно, с использованием legacy com-объектов (изюм .Net), да с многопоточностью, засрёт консоль сообщениями чего ему в этом mono не хватает только для запуска, не говоря о том, что ему будет не хватать для работы. .Net создан для того чтобы интегрировать всё с Windows, а не с целевой платформой.
вообще на рынке сейчас джава актуальная скорее в ынтерпрайзе (j2ee и все что прилагается), c# – тоже актуально (sharepoint), но тут я точно сказать не могу, зависит от ситуации. ТАк что выбор должен основываться на предполагаемых задач, имхо.
Я же стараюсь быть способным решить задачу на обоих платформах, и, как следствие, понимать для чего что лучше использовать
В принципе, зависит от ситуации. Если писать только под Винду, то следует пользоваться Шарпом, ибо .NET со своей библиотекой, да и сам язык в общем-то, уже обогнали Яву по функциональности и удобству написания. Что же касается других ОС – кроссплатформенная среда Mono(для запуска .NET под ОС отличными от Windows), по словам моего знакомого, выполняет код отлично от того как надобно, следовательно, лучше использовать в таких случаях Яву.
25 сентября 2009 в 17:02
#48 Судя по отзывам моих знакомых, чтобы приложение все-таки нормально заработало под Моно, надо изначально писать с учетом этого. Во всех других случаях "чуть переделать клиент" превращается в "переписать полпрограммы". Поэтому в принципе многоплатформенность у .Net есть, но это не основная фича этой платформы.
25 сентября 2009 в 17:01
Стал писать на C# только потому, что нужно было работать с мелкософтовскими продуктами через com. Не жалею, затянуло.
А насчет кроссплатформенности: сейчас популярны веб приложения, а хостингов с виндой уже хватает. Так что с моно в большинстве случаев можно не заморачиваться, ну или чуть переделать клиент, если нужно под линукс.
25 сентября 2009 в 14:04
Ну видимо немного не так поняли друг друга…
Ну вообще, конечно, yield штука полезная)
25 сентября 2009 в 14:04
О, мне нравится: проголосовало 100 человек, 50 за Java, 50 за C#
25 сентября 2009 в 13:05
Ну ладно; чувствую, мы перешли к вопросам терминологии
25 сентября 2009 в 12:04
Жека jkff Кирпичев, Да нет, против IEnumerator ничего не имею, хотя деййсвительно его реализация не является чистой.
public static IEnumerable<int> inf()
{
int i = 0;
while(true)
{
Console.WriteLn("Side Effect");
yield return i++;
}
}
И пожалуйста, будет вам побочный эффект у каждого енамератора, но разумеется этого можно добиться и без использования yield.
Мои претензии не к тому. Мне не нравится метод, который может продолжить выполнение, уже после того, как вернул значение. А термин "чистый" я употребил не в плане отсутвия побочных эффектов, а в плане нарушения концепции функции.
25 сентября 2009 в 9:02
#20 +1
Можно добавить, что java дешевле будет
А вообще, если уж тут затронули "фичи" синтаксиса C# советую прочитать следующую статью: //tinyurl.com/phvq7e
25 сентября 2009 в 9:01
Николай, в общем, возьми код функции inf() и дизассемблируй его при помощи Lutz Reflector – увидишь, что никакими "лишними" побочными эффектами там и не пахнет.
Фактически, получается какой-то такой код:
class Inf : IEnumerable<int> {
private int i;
Inf() {i = 0;}
int Current {get {return i;}}
boolean MoveNext() {i++;}
}
IEnumerable<int> inf() {
return new Inf();
}
25 сентября 2009 в 8:01
В таком случае я повторяю свой вопрос: правда ли, что ты против самой концепции IEnumerator как таковой? Ведь *любая* реализация IEnumerator – через yield ли, или не через yield – не является чистой.
24 сентября 2009 в 23:04
Николай, покажи, пожалуйста, пример кода, доказывающий наличие побочных эффектов *у функции inf()*, а не у методов объекта, возвращенного ею.
24 сентября 2009 в 23:04
Ну если их разделять, то у самой функции побочных эффектов нет. Но при вызове методов Енамератора вызывается код, написанный внутри функции.
24 сентября 2009 в 22:02
Оп-кун, учите оба языка )
24 сентября 2009 в 19:01
Думаю, надо сравнивть по двум критериям: язык и платформа.
Я бы сформулировал так:
Java как язык – более рафинированный, более простой, логичный, менее разлапистый. Все фишки и тонкости, добавленные в C# с одной стороны упрощаю жизнь, с другой усложнят тем, что более сложны для понимания человеком (только не надо писать, что все просто или надо привыкнуть, дело в том, что все равно чем больше "фишек", тем больше напряжение мозга, хотя и подсознательное; даже аозвращение значения через параметр – уже весьма и весьма спорное решение).
Что же касается платформы, то Java – поистине кроссплатформенный (хотя надо знать тонкости и для Mac и для Linux и т.п.), в C# этим пока на серьезном уровне не пахнет.
24 сентября 2009 в 19:00
Ну а в чем я не прав? не будет ленивых вычислений?
public static IEnumerable<int> inf()
{
int i = 0;
while(true)
{
yield return i++;
}
}
Каждое следудщее значение зависит от i,значение i сохраняется внутри функции.
24 сентября 2009 в 18:00
> Может я конечно что-то путаю
Путаешь
#33 – согласен. Считаю, что checked exceptions категорически нужны; более того, с их помощью можно даже слегка моделировать системы эффектов.
24 сентября 2009 в 17:05
> Это неверно. Это функция, возвращающая итератор, ничем не хуже любой другой функции, возвращающей итератор.
Может я конечно что-то путаю но разве такая функция(которая с yield) не начинает хранить в себе состояние? Например локальные переменные этой функции разве сбрасываются при "возвращении значения"? Тут же вообще должны возникать ленивые вычисления, которых в обычных функциях нет, так что это вовсе не обычная функция.
Александр Quyse Lert, да указывать вы можете и в шарпе, другой вопрос нет checked exceptions, но от них сознательно отказались. Вообще сейчас больше распространено мнение, что чекед ексепшинс не нужны
24 сентября 2009 в 17:02
Плюс явы – что метод должен указывать, какие исключения он может кидать. По-моему, дотнету этого недостает.
24 сентября 2009 в 17:00
Уточняю: не-чистыми в обоих случаях являются *методы возвращаемого итератора*, а не функция, которая этот итератор возвращает.
24 сентября 2009 в 16:05
> Проблема в том, что если функция содержит yield return то она больше не функция
Это неверно. Это функция, возвращающая итератор, ничем не хуже любой другой функции, возвращающей итератор.
Нет никакой разницы между
IEnumerable<int> onetwothree() {
yield return 1; yield return 2; yield return 3;
}
и
IEnumerable<int> onetwothree() {
return new int[] {1,2,3};
}
24 сентября 2009 в 16:03
> Так yield return – это просто способ реализации IEnumerator<T>
Ну все есть реализация чегонибудь) Проблема в том, что если функция содержит yield return то она больше не функция, а некое новое синтаксическое явление. Для например Питона это не страшно ибо там функция есть объект, а объект может оказаться функцией) Но для джавы, где это не так, такая конструкция по сути являлась бы новой сущностью
24 сентября 2009 в 16:01
#8, #9
Надо бы знать, что CLR – это реализация CLI, так же как и Mono.
//en.wikipedia.org/wiki/Common_Language_Infrast...
Что касается несовместимости, то полагаю что, как и со всякими другими стандартами, новые версии не сразу поддерживаются всеми реализациями.
Пример приложения, работающего на разных ОС (найдено со странички Mono в Википедии):
//en.wikipedia.org/wiki/Open_Mobile
ЗЫ Кстати, есть еще такая штука, как Silverlight, которая работает и на линухах (см Moonlight), а также имеется реализация под Mac OS.
24 сентября 2009 в 14:01
Ну да… вспоминая JDBC можно слогласиться, не очень хорошо получается с close(), но честно скажу ввесьма редко с этим сталкиваюсь, и не то чтоб меня это сильно напрягало.
> yield return
Ну функция, которя возвращает несколько значений в разные моменты времени довольно суровая штука) По сути, генератор для ПП это новая сущность.
> и укладываются в массивы непосредственно, а не ссылками (и не могут быть null).
Ну да, зато копируются по значению и тем самым сьъедают свой выигрыш в производительности обратно. Хотя в целом против страктов ничего не имею, но особой радости от них тоже не испытываю.
Ну с null это известная проблема, она и в шарпе сплошь и рядом.
24 сентября 2009 в 14:01
Так yield return – это просто способ реализации IEnumerator<T>. Ты, получается, возражаешь против самой идеи итераторов?
24 сентября 2009 в 13:05
using – не согласен, что освобождение ресурсов – редкость.
И как ни крути, синтаксис освобождения ресурсов в джаве – жопа, тем более что какого-то хрена методы close() обычно бросают checked exceptions (ну и что с ними делать?). Освободить несколько, особенно взаимозависимых, ресурсов – синтаксическая каша.
yield return – а какие проблемы с его чистотой?
struct: во-первых, только с -XX:+DoEscapeAnalysis и только в последних версиях джавы; во-вторых, есть и другие отличия, влияющие на производительность, которых от джавы не дождешься: struct занимают меньше памяти за счет отсутствия (видимо) заголовка у объектов, и укладываются в массивы непосредственно, а не ссылками (и не могут быть null).
24 сентября 2009 в 13:03
holly war!!!!!!
holly war!!!!!!
holly war!!!!!!
holly war!!!!!!
holly war!!!!!!
holly war!!!!!!
24 сентября 2009 в 13:03
> reified generics. Сколько граблей из-за generic type erasure в Java!
Ну тут да, генерики в жаве убоги(( проще говоря их нет) Зато есть гарантии, что ход работы программы не зависит от параметризуемого типа, если это понимать в таком ключе, то все становится логично. Всю зависимую функциональность можно делегировать куда-нибудь – громоздко, но гораздо более наглядно.
> – using. Ну знаете ли, если вы не забываете написать юзинг, то не забывайте написать клозе. Да и вообще освобождение ресурсов в жаве – такая редкость, это вам не интерлопом с ком в C# заниматься
> – yield return.
Ну тут да, это полезная штука,пару раз сожалел что ее нет. Но вообще есть некоторые сомнения в ее чистоте для процедурного программирования.
> – делегаты.
нафиг плодить сущности. анонимные классы наше все! хотя тут конечно всплывает отсутвие в джаве нормального метапрограммирования, но это всеравно не повод.
> – struct
Ну авторы джавы клянутся и божатся, что потерь в производителности нет, все что можно выделить на стеке выделяется на стеке и так.
24 сентября 2009 в 13:02
Не согласен, что все приведенные мною особенности шарпа – рюшечки, усложняющие язык. Как минимум, нижеприведенные фичи его, наоборот, упрощают и делают более надежным, удобным, отлаживаемым:
- reified generics. Сколько граблей из-за generic type erasure в Java!
- using. Сколько утечек ресурсов в программах на Java из-за того, что приходится писать грязный, уродливый, повторяющийся и почти не абстрагируемый код для освобождения ресурсов!
- yield return. Как трудно на Java писать сколько-нибудь сложные итераторы из-за отсутствия подобного интуитивного и удобнейшего средства!
- делегаты. Сколько красивых приемов программирования, будучи переведенными на Java, превращаются в грязное месиво из анонимных классов!
- struct: практически нисколько не усложняют язык, однако предоставляют улучшенные возможности для взаимодействия с внешним миром и оптимизации производительности.
Остальное, возможно, можно и отнести к рюшечкам.
24 сентября 2009 в 13:01
Да ладно холивар – мы сами себя тешим
24 сентября 2009 в 13:00
#14
+1
повторюсь
Holly War!!!
24 сентября 2009 в 13:00
Java гораздо более простой и чистый язык. Да в нем нет всяких рюшечек,рюшечки шарпа на мой взгляд часто лишь ухудшают читаемость и отлаживаемость кода, вспомнить хотяб Explicit Interface Implementation.
Я за джаву.
Еще к джаве есть много бесплатных офигенных IDE, которые напишут все за вас)
24 сентября 2009 в 13:00
Согласен. Как язык C#, естественно, развитие Java-языка. Но .Net платформа менее гибка чем Java.
Обосновываю (имею ввиду платформу):
Java-таки нативно работает в большинстве ОС
Java легко расширяется
Java интегрируется со всем что угодно, а не только с продуктами от MS
Java охватывает embedded устройства
Java открыта (таки это свершилось)
Java, как платформа, компактнее
Java имеет транспорты и универсальные коннекторы к "чужим" компонентам
Основные библиотеки Java мультиплатформенны и не прибиты гвоздями к конкретной ОС.
Поймите мою точку зрения, мне нравится C#, но из-за того что он прибит гвоздями к .Net, а .Net впаян в Windows, его применение для меня резко ограничено. Java в этом плане удобнее. Написал один раз и не паришься какие у тебя целевые машины и сервера.
24 сентября 2009 в 12:05
чай или кофе?
высказываемся
24 сентября 2009 в 12:05
а #14 меня опередил))))
24 сентября 2009 в 12:05
#11. Мотивирую:
Фундаментальные (неэмулируемые или очень трудно эмулируемые) преимущества:
- В C# есть reified generics
- В C# есть yield return
- В C# есть struct
- В C# есть unsafe блоки и указатели на крайний случай
- В C# есть expression trees
Синтаксические (эмулируемые) преимущества:
- В C# есть using
- В C# есть out и ref параметры
- В C# есть замыкания с приличным синтаксисом (делегаты и собственно лямбды)
- В C# есть events
- В C# есть много другого удобного синтаксиса: collection и object initializers, local type inference
- В C# есть LINQ
24 сентября 2009 в 12:04
#14
+1
Хотя тут не обсуждение что лучше. Тут доказывают, что если к протвиню от Electrolux плиты примотать проволоку, да дырочек насверлить, то его, наверное, можно будет подвесить на треногу и попытаться сварить в нём суп (только через каждые 5 секунд вода будет выливаться).
"вы всё ещё завариваете чай в коптильне установленой на пароварку? ммм.. мы вызываем санитаров к вам."
Очень похоже на попытки перетащить что-нибудь .Net-ое на Mono.
P.S: А котелок-то подходит для того чтобы его в духовку поставить!!
24 сентября 2009 в 12:03
зато если с годик другой поюзаешь C#, потом очень тяжело работать с другими технологиями, настолько затягивает)
24 сентября 2009 в 12:03
C# как язык гораздо более продвинут и "правильно" сделан, нежели Java.
24 сентября 2009 в 12:03
#10, если годик поработаешь в ФСБ, то, наверное, тоже тяжело работать программистом – затягивает
24 сентября 2009 в 12:03
#11 -обоснования и ссылки в студию. "Правильность" – очень субъективно, хотя не лишено логики, т.к. c# делался по образу и подобию Java с максимальной на неё оглядкой : //ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D0%B...
24 сентября 2009 в 12:03
(1) что лучше чайник или кастрюля?
(2) лучше всего протвинь!
(3) и как ты на треноге протвинь крепить собираешься? лучше походного котелка ничего быть не может!
(4) чёго вы все несёте ни в котелке ни на протвине коптить не получится, надо нормальную rкоптильню.
<…>
вы всё ещё завариваете чай в коптильне установленой на пароварку? ммм.. мы вызываем санитаров к вам.
24 сентября 2009 в 12:02
#7 Как язык для CLR может быть кроссплатформенным? Поясните ваше высказывание. Естественно, в данном треде кроссплатформенностью считается возможность запуска в различных ОС.
24 сентября 2009 в 12:01
Надо бы знать, что Mono – это open source проект, соответственно, MS на него плевать и каждый чих в спецификации платформы .Net и основных #-языков заставляют переписывать огромные участки кода проекта. Тем более на mono даже и не пахнет полноценной заменой _платформы_ .Net, не говоря уже о том, что C# и .Net вне Windows _бесполезны_. Hello world, написанный на C#, конечно запуститься, но любой энтрепрейс, особенно, с использованием legacy com-объектов (изюм .Net), да с многопоточностью, засрёт консоль сообщениями чего ему в этом mono не хватает только для запуска, не говоря о том, что ему будет не хватать для работы. .Net создан для того чтобы интегрировать всё с Windows, а не с целевой платформой.
24 сентября 2009 в 11:05
Как уже писали выше, есть Mono, так что в C# кроссплатформенность в принципе есть…
24 сентября 2009 в 11:03
Конечно лучше, в C# её нет в принципе.
24 сентября 2009 в 10:04
Да, видимо в Java лучше с кросплатформенностью…
24 сентября 2009 в 10:03
вообще на рынке сейчас джава актуальная скорее в ынтерпрайзе (j2ee и все что прилагается), c# – тоже актуально (sharepoint), но тут я точно сказать не могу, зависит от ситуации. ТАк что выбор должен основываться на предполагаемых задач, имхо.
Я же стараюсь быть способным решить задачу на обоих платформах, и, как следствие, понимать для чего что лучше использовать
24 сентября 2009 в 10:01
В принципе, зависит от ситуации. Если писать только под Винду, то следует пользоваться Шарпом, ибо .NET со своей библиотекой, да и сам язык в общем-то, уже обогнали Яву по функциональности и удобству написания. Что же касается других ОС – кроссплатформенная среда Mono(для запуска .NET под ОС отличными от Windows), по словам моего знакомого, выполняет код отлично от того как надобно, следовательно, лучше использовать в таких случаях Яву.
24 сентября 2009 в 9:05
Я прогаю на С#.
Реально ет холвар