Здравствуйте, BlackTigerAP, Вы писали:
BTA>Кстати, насчет "если знаешь Цпп, то на C# перейти очень просто"... А вот нифига подобного! Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.
BTA>Легко переходят Дельфийцы!
Здравствуйте, Mr. None, Вы писали:
MN>Да нет, скорее наоборот понимают, но не простоту и мощность, а ущербность и #$@нутость... MN>Извините, пока читал терпел сколько мог, но всё равно не смог удержаться от комментария...
Ну, это только ущербные и #$@ные... Шутка.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, BlackTigerAP, Вы писали:
BTA>>Кстати, насчет "если знаешь Цпп, то на C# перейти очень просто"... А вот нифига подобного! Многие "проблемы" возникают именно у тех, кто переходит с Цпп. Они просто не понимают простоты и мощности C#.
BTA>>Легко переходят Дельфийцы!
VD>Наше голосование показало
, что большая часть перешедших как раз С++-ники.
Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No. Кстати, радуют двое человек, которые перешли с ASM. Все ребята, assembler умирает, да здраствует NET.
BTA>>Создатель-то тот же!
Легче всего тем кто на Java. Концепция та же.
И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.
Здравствуйте, GlebZ, Вы писали:
GZ>Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No.
Откровенно говоря не много я знаю народу кто вообще держит спецификацию плюсов под боком.
С другой стороны понятно, что ничего сразу не забывается. Да этого и не нужно. Просто использоваться начинается менее плотно или вообще не используется. Я плюсы в руки за последние два года брал наз 30. И в основном для тестов.
GZ> Кстати, радуют двое человек, которые перешли с ASM. Все ребята, assembler умирает, да здраствует NET.
BTA>>>Создатель-то тот же! GZ>Легче всего тем кто на Java. Концепция та же.
Ага. А еще легче тем кто на ВБ. Принципы то те же...
Не смешно? Дотнет вообще не привязан к языку. Если уж говорить, то о Шарпе. А Шарп впитал в себя целую тучу концепций из кучи языков. Из Явы конечно не мало, но и из Дельфи тоже. Да и из плюсов кучу. Более того ВБ + Дельфи + С++ полностью перекрывают возможности Явы. Ява появилас позже чем все эти языки. Так что спор о том кто у гого что перенял не очень осмысленный.
Просто всем. Просто потому, что в Шарп грамотно спроектирован. И потому что в нем встречаются знакомые концепции. Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования. Дельфисту что такое ArrayList. Явщику что такое делекаты. Ну, и т.п.
GZ>И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.
Гы. А спецификация то у Шарпа посложнее чем у С++. Выучить ее на изусть не так то просто. Тут в другом дело. Она содержит меньше заморочек и больее однозначана. Это приводит к тому, что ее ненужно заучивать. Она в основном интуитивно понятна.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Гы. А спецификация то у Шарпа посложнее чем у С++.
Ну вот я этого не понимаю. Что значит сложнее? Более объемная контекстно-свободная грамматика? Дак это еще ни о чем не говорит. Вернее говорит. Говорит, что С# легче поддается для формализации в виде контекстно-свободной грамматики. ИМХО, это может означать, что С# проще. (а может и не означать )
VD>Просто потому, что Шарп грамотно спроектирован.
Вот уж поспорил бы я с вами по этому поводу, да времени нет. Могу только пример привести:
0 — это ноль типа int;
DataRow хранят элементы в виде object;
запись row[0] = 0 означает, что в 0-вую колонку строки заносится нулевое значение типа int; ВНИМАНИЕ, а если 0-вая колонка в базе имеет тип соответствующий шарповскому decimal мы имеем ошибку периода исполнения! В простейшем случае, когда запись в DataRow приводит к записи в базу, найти такой косяк просто. А вот в моём случае система имела 3-ёх звенную архитектуру и запись данных в контейнер (DataSet) происходило на одном конце, а сброс этого контейнера в базу — на другом, между ними был ASP.NET и ремоутинг. Если бы вы знали, как я задолбался вылавливать такие косяки, посто потому что постоянно забывали писать 0m (0 типа decimal) и писали 0 (0 типа int — почувствуй разницу). В данном случае ущерб от срезки при нявном приведении типов был бы и того меньше — в конце концов, можно было бы бросать исключении только при срезке, а во всех остальных случаях пропускать преобразование (в нашем случае это тоже бы подошло, потому что руками мы инициализировали только нулевые значения)... А наличие шаблонов или по крайней мере контроля типов при выполнении в самой строке (в непосредственной близости от точки неверной инициализации) было бы совсем идеальным. Это не ошибка в архитектуре приложения — это пример неграмотного проектирования самого языка и его библиотеки.
VD>И потому что в нем встречаются знакомые концепции.
VD>Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования.
Вот отсутсвие множественного наследования — это последнее, что мне мешало пользоваться Шарпом. А на первых 3-ёх местах было:
1) отсутствие шаблонов — только не надо поднимать флейм на тему, что можно и без шаблонов обойтись — не всегда можно — или что в спецификации шарпа 2.0 шаблоны уже есть — это не те шаблоны, они слишком ущербны;
2) обработка ошибок через сброс исключений в сочетании с отсутствием RAII — я уже говорил на эту тему, почему нельзя было разрешить деструкторы у размерных типов;
3) отсутствие друзей — иногда бывает нужно одному классу или функции предоставить доступ к некоторым закрытым полям класса, модификатор internal с этим не справляется, написание соответствующего атрибута тоже не пойдёт — я хочу знать, что я не прав при компиляции, а не при демонстрации у заказчика.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
GZ>>Посчитай, сколько народу учило или учат в институтах C++ и сколько Delphi. И не очень нравится глагол "переходят". Такое впечатление что они нажимают какую-то кнопку, Стереть файл: Спецификация С++ Yes No.
VD>Откровенно говоря не много я знаю народу кто вообще держит спецификацию плюсов под боком. VD>С другой стороны понятно, что ничего сразу не забывается. Да этого и не нужно. Просто использоваться начинается менее плотно или вообще не используется. Я плюсы в руки за последние два года брал наз 30. И в основном для тестов.
Я знаю достаточно много. Например мы: основная часть написана на Delphi, некоторые системные части на C++, Web на ASP.NET. Есть еще несколько знакомых фирм, с подобными проблемами. На мой взгляд, связка типа Delphi+C++ или NET + C++ оптимальна. Класть некоторые системные вещи на NET не является оптимальным решением.
BTA>>>>Создатель-то тот же! GZ>>Легче всего тем кто на Java. Концепция та же.
VD>Ага. А еще легче тем кто на ВБ. Принципы то те же...
Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление. VD>Не смешно? Дотнет вообще не привязан к языку. Если уж говорить, то о Шарпе. А Шарп впитал в себя целую тучу концепций из кучи языков. Из Явы конечно не мало, но и из Дельфи тоже. Да и из плюсов кучу. Более того ВБ + Дельфи + С++ полностью перекрывают возможности Явы. Ява появилас позже чем все эти языки. Так что спор о том кто у гого что перенял не очень осмысленный.
Абсолютно не осмысленный. Согласись, что на 90% С# как язык зависит от платформы и самой концепции NET. Я бы даже сказал так, С# — это некоторый С++ язык наиболее полно отражающий возможности платформы NET, и в котором убраны концепции не используемые на данной платформе. Еще бы возможность в некоторых отдельных случаях перевести управление boxингом в ручной режим, было бы круто. Хотя я понимаю почему это не было сделано.
VD>Просто всем. Просто потому, что в Шарп грамотно спроектирован. И потому что в нем встречаются знакомые концепции. Так же сложно всем, так как Шарп отличается от всех перечисленных языков. С++ непонятно как можно жить без множественного наследования. Дельфисту что такое ArrayList. Явщику что такое делекаты. Ну, и т.п.
Некоторая поправка. С++ можно жить без множественного наследования (невелика потеря, по опыту знаю что множественным наследованием в своем коде пользовались немногие разработчики, в основном это была пререгатива различных библиотек типа STL, ATL). Значительно важнее отсутсвие ручного управления памятью и указатели. Для Дельфиста понятна что такое ArrayList, есть аналог, но при этом надо сразу сказать что это объект не языка а стандартного объекта (не будем же мы говорить что в VB.NET его нет). Дельфисту труднее понять систему Binding. И им обоим будет непонятно, что такое GC, и отсутсвие детерменированных деструкторов. Про яву не могу ничего сказать, так как не знаю языка. Хотя сразу скажу, что управление памятью весьма похожа. Им не придется менять мышление. Итого, важнее платформа, чем синтаксис.
GZ>>И вообще, спецификацию языка выучить значительно легче и не важно С# или VB. Значительно труднее понять NET.
VD>Гы. А спецификация то у Шарпа посложнее чем у С++. Выучить ее на изусть не так то просто. Тут в другом дело. Она содержит меньше заморочек и больее однозначана. Это приводит к тому, что ее ненужно заучивать. Она в основном интуитивно понятна.
Что касается С# 1.0, то не согласен. То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий. С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.
Здравствуйте, prVovik, Вы писали:
VD>>Гы. А спецификация то у Шарпа посложнее чем у С++. V>Ну вот я этого не понимаю. Что значит сложнее? Более объемная контекстно-свободная грамматика?
С чего ты взял что у шарпа контекстно-свободная грамматика?
Здравствуйте, AndrewVK, Вы писали:
AVK>С чего ты взял что у шарпа контекстно-свободная грамматика?
Я этого не говорил. КС грамматика используется для облегчения построения парсера, поскольку в данном случае процесс можно автоматизировать.
Здравствуйте, prVovik, Вы писали:
AVK>>С чего ты взял что у шарпа контекстно-свободная грамматика? V>Я этого не говорил. КС грамматика используется для облегчения построения парсера, поскольку в данном случае процесс можно автоматизировать.
Здравствуйте, AndrewVK, Вы писали:
AVK>И? В чем твоя исходная мысль была?
В том, что ошибочно делать выводы о сложности КЗ языков на основе КС грамматик, применяемых для построения синтаксических анализаторов этих языков, так как объемная КС грамматика может свидетельствовать о том, что язык лучше поддается формализации КС грамматикой, что само по себе говорит скорее о простоте, нежели о сложности.
Здравствуйте, prVovik, Вы писали:
AVK>>И? В чем твоя исходная мысль была? V>В том, что ошибочно делать выводы о сложности КЗ языков на основе КС грамматик, применяемых для построения синтаксических анализаторов этих языков, так как объемная КС грамматика может свидетельствовать о том, что язык лучше поддается формализации КС грамматикой, что само по себе говорит скорее о простоте, нежели о сложности.
Все равно не понял. О КС-грамматиках речь завел ты. И из своих же слов сделал вывод.
Сложность же спецификации, о которой говорит Влад, состоит в том, что у шарпа просто больше синтаксических конструкций, и сами конструкции сложнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Все равно не понял. О КС-грамматиках речь завел ты. И из своих же слов сделал вывод.
Цитата:
Что значит сложнее? Более объемная контекстно-свободная грамматика?...
То есть мои слова надо понимать так: "Если Влад сделал свой вывод на основе сложности КС грамматики, то это неправильно". Я ни с кем не спорил. Просто высказал мысль. Вот и все. Никакого потайного смысла.
AVK>Сложность же спецификации, о которой говорит Влад, состоит в том, что у шарпа просто больше синтаксических конструкций,
Это само по себе еще ни о чем не говорит.
AVK>и сами конструкции сложнее.
А вот об этом по подробнее. Сложнее, чем что? Чем разрешение перегрузки? Чем ODR? Чем SFINAE? Чем поиск имен в шаблонах (ADL)? Чем частичная специализация шиблонов (правила формального упорядочивания)? Чем виртуальное наследование?
Да по некоторым таким моментам можно отдельные книги выпускать.
Здравствуйте, prVovik, Вы писали:
AVK>>и сами конструкции сложнее. V>А вот об этом по подробнее. Сложнее, чем что? Чем разрешение перегрузки? Чем ODR? Чем SFINAE? Чем поиск имен в шаблонах (ADL)? Чем частичная специализация шиблонов (правила формального упорядочивания)? Чем виртуальное наследование? V>Да по некоторым таким моментам можно отдельные книги выпускать.
Это свидетельство не сложности, а запутанности и неоднозначности. Неинтуитивности, если хочешь. Поведение, к примеру, дотнетных событий тоже штука не тривиальная, особенно если разбираться полностью, вплоть до того, как их обрабатывает JIT или маршаллер. Однако знать все это мало кому интересно, поскольку поведение делегата интуитивно понятно. Или вот еще пример — енумы. Сложнее плюсовых просто на порядок. Тем не менее, как правило, программисту это никаких особых проблем не доставляет.
Здравствуйте, Mr. None, Вы писали:
MN>0 — это ноль типа int;
MN>DataRow хранят элементы в виде object; MN>запись row[0] = 0 означает, что в 0-вую колонку строки заносится нулевое значение типа int;
... То что ты описывашь — это даже не косяк. С нулем есть другой косяк. Но это уже другая история...
MN>Если бы вы знали, как я задолбался вылавливать такие косяки, посто потому что постоянно забывали писать 0m (0 типа decimal) и писали 0 (0 типа int — почувствуй разницу).
А кто мешал просто пользоваться типизированным датасетом? Тогда работала бы статическая проверка типов и ошибок в рантайме вообще небыло бы.
Ты бы еще посетовал, на то что завел булеву пременную и теперь в программе появляются ошибки так как эта переменная иногда получает значение false.
MN> В данном случае ущерб от срезки при нявном приведении типов был бы и того меньше — в конце концов, можно было бы бросать исключении только при срезке, а во всех остальных случаях пропускать преобразование (в нашем случае это тоже бы подошло, потому что руками мы инициализировали только нулевые значения)...
Еслы бы ты знал сколько ошибок появляется в программах из-за вот такого неявного приведения типов, то вряд ли бы ты за это радовл.
К тому же описанный тобой случай к приведению типов имеет очень отдаленное отношение. Как раз неявное преобразование типов от int к более большим (тому же децемалу) в Шарпе разрешен, так как это не может привести к проблемам. Но в твоем случае речь идет о анбоксинге. Тут действительно любые преобразования недопускаются. И это иногда действительно неудобно. Однако в других языка нет даже самого боксинга. Так что сравнивать его попросту не с чем.
MN> А наличие шаблонов или по крайней мере контроля типов при выполнении в самой строке (в непосредственной близости от точки неверной инициализации) было бы совсем идеальным.
А теперь подумай чья это проблема, языка или того кто писал датасет? Как, по-твоему, трудно было сделать подобную проверку в датастете?
А вот автоматическое приведение при анбоксинге может привести к проблемам в других метах.
Кстати, если нужно автоматическое приведение при анбоксинге, то достаточно использвать методы серии Converter.ToXxxTyoe(). И то что их не использовали в ДатаСете прискорбно, но это никак не является проблемой самого языка.
MN> Это не ошибка в архитектуре приложения — это пример неграмотного проектирования самого языка и его библиотеки.
Ну, выше я вроде все растолковал. Надеюсь доходчиво...
MN>Вот отсутсвие множественного наследования — это последнее, что мне мешало пользоваться Шарпом.
А я вот, бывает, сетую на невозможность подключить котовую реализацию.
MN> А на первых 3-ёх местах было: MN>1) отсутствие шаблонов — только не надо поднимать флейм на тему, что можно и без шаблонов
Действительно можно. Хотя и действительно неудобно.
MN> обойтись — не всегда можно — или что в спецификации шарпа 2.0 шаблоны уже есть — это не те шаблоны, они слишком ущербны;
Они полностью решают поставленные перед ними задачами. Твое их незнание еще не делает их ущербынми. Ими конечно нельзя пробки открывать и гвозди забивать. Но это, к счастью, и не надо.
MN>2) обработка ошибок через сброс исключений в сочетании с отсутствием RAII — я уже говорил на эту тему,
Чуть-чуть попрограммировав на Шарпе станоится очевидным что нет никаких проблем с управлением ресурсами в этом языке. После того как отпадает необходимость управлять освобождением памяти управление другими ресурсами становится детской задачей. Конструкция "using ()" с успехом решает эту задачу.
MN>почему нельзя было разрешить деструкторы у размерных типов;
Потому-что это усложнение языка которое не имеет смысла на практике.
MN>3) отсутствие друзей — иногда бывает нужно одному классу или функции предоставить доступ к некоторым закрытым полям класса, модификатор internal с этим не справляется, написание соответствующего атрибута тоже не пойдёт — я хочу знать, что я не прав при компиляции, а не при демонстрации у заказчика.
Опять таки выдуманная проблема появляющаяся из-за ущербности взгляда С++-ника. Это проблема не языка, а ограничение платформы, или даже технологии. Дотнет компонентная среда. Модификаторы доступа — это средства обеспечения защиты кода. Они работают на уровше модулей (сборок). "Друзья" же есть парадигма которую можно реализовать только в рамках одной сборки. И опять же на практике нет никаких проблем. Так что забивать себе голову вообще ненужными вещами?
В С++ есть еще сотни фич которые можно называть полезными. Но правда в том, чно 99% из них нафиг не нужны и с успехом заменяются другими решениями. Если привнести их все в язык, то язык станет таким же запутанными и монстроидальным как С++.
Сравнение С++ и Шарпом будет явно не пользу С++. Я могу назвать десяки плохих примеров из этого языка. Причем все они будут именно прмерами непродуманного дизайна.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>Я знаю достаточно много. Например мы: основная часть написана на Delphi, некоторые системные части на C++, Web на ASP.NET. Есть еще несколько знакомых фирм, с подобными проблемами. На мой взгляд, связка типа Delphi+C++ или NET + C++ оптимальна. Класть некоторые системные вещи на NET не является оптимальным решением.
1. Довольно неразумно противопоставлять С++ дотнету, так как для дотнета без проблем можно писать на С++.
2. В большинстве случае применение С++ мало чего дает. Хотя конечно всегда можно найти задачу где его использование будет более удобное.
VD>>Ага. А еще легче тем кто на ВБ. Принципы то те же... GZ>Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление.
Причем тут это? Что по твоему в Шарпе мало похожих с ВБ чер?
GZ>Абсолютно не осмысленный. Согласись, что на 90% С# как язык зависит от платформы и самой концепции NET.
Зачем созлашаться с явно неверными утверждениями? Моно уже полнейшее доказательство неврности этих слов. Да и вообще Шарп нужнается в основном только в GC, а GC реализован в куче рантаймов языков не относящихся в к дотнету.
То что Шарп прекрасно вписывается в концепции дотнете не мудренно. Он же для нее проектировался. Но это еще не значит, что Шарп не может быть реализован без дотнета. Шарп не содержит в себе ни единой новой концепции. Все что в енм есть было и до него. Просто оно было распределено по доброму десятку других языков.
GZ> Я бы даже сказал так, С# — это некоторый С++ язык наиболее полно отражающий возможности платформы NET, и в котором убраны концепции не используемые на данной платформе. Еще бы возможность в некоторых отдельных случаях перевести управление boxингом в ручной режим, было бы круто. Хотя я понимаю почему это не было сделано.
Откровенно гворя с С++ у шарпа общие в основном названия ключевых слов и скобки. Концептуально яыки различаютс очень сильно.
GZ>Некоторая поправка. С++ можно жить без множественного наследования (невелика потеря, по опыту знаю что множественным наследованием в своем коде пользовались немногие разработчики, в основном это была пререгатива различных библиотек типа STL, ATL).
Да без разницы что знакомого ты ненайдешь в Шарпе. Главное что ненайдешь! Так же как без разницы что знакомог ты найдешь в Шарпе.
GZ> Значительно важнее отсутсвие ручного управления памятью и указатели. Для Дельфиста понятна что такое ArrayList, есть аналог, но при этом надо сразу сказать что это объект не языка а стандартного объекта (не будем же мы говорить что в VB.NET его нет).
Его нет в ВБ 6. Да и в ВБ.НЭТ его используют не очень часто (хотя и зря), так как в ВБ есть встроенные динамические массивы.
GZ> Дельфисту труднее понять систему Binding.
Понятия Binding ни в языках дотнета, ни в CLR нет. Это идиома высокоуровневых библиотек. Не мешай мух с котлетами.
GZ> И им обоим будет непонятно, что такое GC, и отсутсвие детерменированных деструкторов.
В Дельфи нет автоматически вызваемых методов очистки. А вызываемые вручную можно реализовать где угодно. Так что Дельфисту тут все будет понятно.
GZ> Про яву не могу ничего сказать, так как не знаю языка. Хотя сразу скажу, что управление памятью весьма похожа. Им не придется менять мышление. Итого, важнее платформа, чем синтаксис.
И какая Платформа у С++ или Дельфи? Блин, оба языка без проблем используются для создания менеджед-кода. Дельфи так вообще даже серьезных изменений не претерпела, так как концептуально очень близка.
В общем, не нужно выдумывать сказок. Шарп — это сборная солянка со всех императивный языков существовавших до этого. Больше всего Шарп перенял из Явы и ВБ. Но это и это утверждение спорно. Дотнет является рантаймом для Шарпа. Потенциально шарп без проблем можно реализовать и на другом рантайме. Просто это мало кому нужно.
GZ>Что касается С# 1.0, то не согласен.
И давно ты читал спецификацию? Хотя судя по всему ты ее в глаза не видел, так как должен бы знать, что текущая спецификация шарпа имеет версию 1.2.
GZ> То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий.
Спецификация 2.0 распухла где-то процентов на 5-10. Но дело не в этом. Выучить ее на изусть очень непросто. Но учить ее на изусть смысла особого не имеет. В Шарпе настолько мало противоречий и алогизмов, что достаточно понимать его концепции.
GZ>С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.
Понимание памяти?
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Довольно неразумно противопоставлять С++ дотнету, так как для дотнета без проблем можно писать на С++.
Без проблем? Впервые слышу. Сначало надо выучить что в данном managed С++ можно делать и что нельзя, научиться вставлять __gc и еще кучу параметров. Это уже не очень похоже на то что описывает Страуструп, это отдельный язык. И достаточно непохожий. VD>2. В большинстве случае применение С++ мало чего дает. Хотя конечно всегда можно найти задачу где его использование будет более удобное.
Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.
VD>>>Ага. А еще легче тем кто на ВБ. Принципы то те же... GZ>>Например, отсутсвие наследования. Для того чтобы сделать хороший дизайн, разработчику надо будет перестроить мышление.
VD>Причем тут это? Что по твоему в Шарпе мало похожих с ВБ чер?
Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление. Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление. Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной. Потом появился OLE со всеми причендалами, то же самое. Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...
Мне плевать какими словами я запишу алгоритм, но мне не плевать на окружающую среду, если от этого зависит архитектура и дизайн, именно от этого зависит какой будет алгоритм.
В данном случае, есть маленькое изменение, которое затрагивает дизайн, и соответсвенно требует переосмысления инструментов, которыми ты пользуешься. Одно это маленькое (в кавычках) изменение открывает широкие горизонты по сравнению с VB6.
....skip VD>Понятия Binding ни в языках дотнета, ни в CLR нет. Это идиома высокоуровневых библиотек. Не мешай мух с котлетами.
...skip
Все эту шнягу, я написал чтобы показать, что окружение первично, а не язык. Нафиг нужен CRL без высокоуровневых библиотек. Запишем высокоуровневые библиотеку как часть платформы, или окружения, как вам будет угодно. Все таки поставка, одна.
VD>И какая Платформа у С++ или Дельфи? Блин, оба языка без проблем используются для создания менеджед-кода. Дельфи так вообще даже серьезных изменений не претерпела, так как концептуально очень близка.
При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет, и следовательно, он мне в таком виде не интересен (если спросите что там изменилось, не отвечу. Мне это неинтересно. Я не слышал мнений программировать под NET для Delphi круче чем на VS+С#. Так что не вижу смысла).
VD>В общем, не нужно выдумывать сказок. Шарп — это сборная солянка со всех императивный языков существовавших до этого. Больше всего Шарп перенял из Явы и ВБ. Но это и это утверждение спорно. Дотнет является рантаймом для Шарпа. Потенциально шарп без проблем можно реализовать и на другом рантайме. Просто это мало кому нужно.
GZ>>Что касается С# 1.0, то не согласен.
VD>И давно ты читал спецификацию? Хотя судя по всему ты ее в глаза не видел, так как должен бы знать, что текущая спецификация шарпа имеет версию 1.2.
Давно, читал, в 2001 году. Ну извините, перечитать как-то не удается, приходится работать, зарабатывать хлеб насущный в том числе и на C#. Но как только, так сразу .
GZ>> То что касается 2.0 умолчу, потому что знаю только по статьям. Вообще у кого больше по объему спецификация вопрос дурацкий.
VD>Спецификация 2.0 распухла где-то процентов на 5-10. Но дело не в этом. Выучить ее на изусть очень непросто. Но учить ее на изусть смысла особого не имеет. В Шарпе настолько мало противоречий и алогизмов, что достаточно понимать его концепции.
Поскольку моей единственной информацией была именно ваша статья, поверю. Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?
GZ>>С# за счет отсутсвия ссылок на память в managed коде действительно значительно облегчает ее понимание.
VD>Понимание памяти?
Ну "его", смысл то понятен.
Здравствуйте, GlebZ, Вы писали:
GZ>Задачи сами тебя находят. Например, пришла к нам одна программа одного достаточно известного производителя на NET. Она хоть и конечно сервер, но требовать 1Г оперативной памяти в requariments для работы, это слишком.
Весомый аргумет при выборе языка обучения. Да и гиг на сенодня серьезная пробелма.
GZ>Имеется, конечно, ввиду VB6. Собственно наплевать на то, какими словами ты пишешь for или if или даже наличие foreach. Когда-то я начинал с модульного программирования. Потом прочитал хорошую книгу и начал писать на OOP. Важно что изменились не только стиль программы, изменилось мышление. GZ> Потом, я начал писать для Windows 3.1. Прочел хорошую книгу, и сново изменилось мышление.
А у меня все с точностью на оборот. Я сначала начал писать в ОО-стиле на С и потом я нашел С++ который позволял мне присать в этом стиле более просто. Потом я начал писать на С++ в компонетном стиле и использовать разные идиомы вроде ссылок на методы экземпляра. Потом я нашел Шарп который позволил мне делать все тоже самое намного проще и изящьнее.
GZ> Уже не было проблем с интерфейсом, зато появились чудеса квазимногозадачности. Дальше начал работать на Windows 95+NT, здесь перестройка ума, не была настолько существенной.
Опять же. Я сначал попытался сам написать нкую оконную оболочку (на С) под текстовый режим, а уже потом увидил виндвос. При этом виндовс показался очень понятным и ничего менять в голове не пришлось.
GZ> Потом появился OLE со всеми причендалами, то же самое.
И опять же. Оле (вренее КОМ) для меня стало методом позволяющим добавить компонентность в мои программы.
GZ> Потом пересел на ASP. Ты знаешь как трудно привыкать к тому, что у тебя общение с пользователем всего лишь два стрима, response-request. Далее NET...
Нет. Незнаю. АСП для меня выглядело как решение на базе КОМ и КОМ-скриптов.
GZ>Мне плевать какими словами я запишу алгоритм, но мне не плевать на окружающую среду, если от этого зависит архитектура и дизайн, именно от этого зависит какой будет алгоритм. GZ>В данном случае, есть маленькое изменение, которое затрагивает дизайн, и соответсвенно требует переосмысления инструментов, которыми ты пользуешься. Одно это маленькое (в кавычках) изменение открывает широкие горизонты по сравнению с VB6.
А для меня все это выглядит как обычное итеративное развитие. Просто всзяли из ВБ все лучшее. Выкинули худшее и вуаля.
GZ>Все эту шнягу, я написал чтобы показать, что окружение первично, а не язык. Нафиг нужен CRL без высокоуровневых библиотек. Запишем высокоуровневые библиотеку как часть платформы, или окружения, как вам будет угодно. Все таки поставка, одна.
Вот опять смешал катлеты с мухами. Язык есть язык. ЦЛР есть ЦЛР. А библиотеки (не поверишь) есть библиотеки. В стандарт шарпа входит описание минимума библиотек без которых язык не мыслим. Но остальные — это средство поддржки программирования для кокретных задач (АСП, Виндовс ГУИ и т.п.) и для изучения программирования, а точнее для правильного понимания, что такое программирование все они ненужны. Ну, ненужно АСП.НЭТ для того чтобы научиться программировать. А вот язык нужен.
GZ>При C++ я уже написал свое мнение. Что касается Delphi, кому надо, пускай упражняются, но легкого переноса кода не будет,
Ага. Вот только есть. Программы не использующие явной работы с указателями (а это редкость для Дельфи) и компонетнов третьих фирм, без проблем перекомпилируются в менеджед-приложения.
GZ> и следовательно, он мне в таком виде не интересен (если спросите что там изменилось, не отвечу. Мне это неинтересно. Я не слышал мнений программировать под NET для Delphi круче чем на VS+С#. Так что не вижу смысла).
Дык сделай поиск по сайту и увидишь и такие.
GZ>Давно, читал, в 2001 году.
Т.е. до того как была выпущена первая версия дотнета, и соотвествено, спецификация шарпа?
GZ> Ну извините, перечитать как-то не удается, приходится работать, зарабатывать хлеб насущный в том числе и на C#. Но как только, так сразу .
Кстати, очень советую. Написан текст очень доходчиво и это занятие дает очень много с точки зрения понимания концепции языка.
GZ>Поскольку моей единственной информацией была именно ваша статья, поверю.
Давай лучше на ты. А то тут Вы начинают коворить при переходе на личности.
GZ> Однако как сильно воздействуют эти изменения. Приведу пример из практики. Делалась программа на С++, использовался ATL, STL. Один программер попросил совета. Не помню в чем была ситуация, но решалась она красиво с помощью создания template. Программер, который писал на ATL, STL, был весьма хороший человек и коллега, как оказалось не умел этого делать. Через некоторое время, то же самое произошло с другим программером, в той же группе. Достаточно поучительный для меня случай был. Каким параметром это измерить?
Сложностью изучения и применения технологии. Шаблоны в С++ стали слишком важной частью языка. Ими уже не решают проблемы дженерик-прграммирования, а натуральным образом модифицируют язык. Такие повороты не для каждого проходят гладко. Александреску сорвал крышу не одного программиста. АТЛ и СТЛ по сравнению с Локи и Бустом все же очень простые библиотеки. Хотя лично мне многое из АТЛ в свое время нравилось.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это свидетельство не сложности, а запутанности и неоднозначности. Неинтуитивности, если хочешь.
Стоп. Изначатьно была фраза Влада:
А спецификация то у Шарпа посложнее чем у С++.
Я с ней не согласлся и привел очень сложные вещи из С++, описанные в его спецификации. Ничего подобного в С# нет. На фоне этих "штучек" C# кажется детской песенкой. О запутанности и неинтуитивности речи не шло.
Пример: в С# отсутствует частичная специализация шаблонов, и как следствие в его спецификации нет нетривиального алгоритма поиска наиболее специализированного шаблона. Стал он от этого проще? Да. Но его простота достигнута в ущерб функциональности.
