Visual Studio Express

[mineral]

Самое главное, это лицензионные условия...

Express - это bare bones of Visual Studio... Небольшое количество project templates...

SQL Server Express, который идет с ней, имеет ограничение на размер баз данных - 2GB. Неэффективен с большим количеством одновременных сonnections... Где-то 5-7 - максимум для оптимальной работы....

Есть, наверное, еще что-то... Я не изучал экспресс в деталях....

[mineral]

Все эти "Visual" в эпоху "господства xml для диалоговых интерфейсов" даже скорее мешать начинают чем помагать. Ведь когда объединяют в одной среде систему управления проектом и кучу всего остального - получается какой-то идиотизм.
Кроме того "автоматически сгенерированный текст программы" всё равно потом лучше "изменять вручную"....;)

Майк, ты, наверное, имеешь в виду HTML... Ну, ASP .NET rocks...

Попробуй, поработай над большим проектом вручную... Если есть пара лишних лет, то конечно, будет интересно...

[crazy-mike]

Майк, ты, наверное, имеешь в виду HTML... Ну, ASP .NET rocks...
...

;)
Visual Express - не является системой управления проектом на самом деле (система управления проектом должна включать элементы верификации проекта, а есть ведь ещё и методы автоматизированной оптимизации проекта - потоков данных и т.д. Visual Studio в этом отношении просто не может "конкурировать" с какой-нибудь Rational Rose. Да и не должна. По большому счёту - Visual является интерактивной tutorial для студентов-первокурсников. Хотя с "аналогами" от Borland работать удобнее). Visual - там вообще звучит довольно "обманчиво".
Основная идея всех Visual "от Microsoft" сводится к тому - чтобы "спрятать ошибки в реализациях своих собственных библиотек классов".
:grum:
Не совсем. Для бизнес-приложений в самом деле использовались когда-то "генераторы кода" (и даже целое направление было - 4GL).
Только результат был - "не особенно хороший". Обычно вся совокупность проблем именовалась "нестабильно работающее приложение". В последнее время наблюдается немного другая тенденция - "большой проект" преобразуется в совокупность "взаимодействующих маленьких" и даже - "самоорганизующихся взаимодействующих маленьких" (это когда "задача" спрашивает - "у кого мне получить данные" , какая-то другая отвечает и т.д.
Очень похоже на "архитектуру Jini". SOAP - тоже придерживается этих принципов ). "Большие монолитные" практически "отжили свой срок" (по большому счёту их практически никогда и не существовало). Кроме того - желательно избавиться от необходимости "перекомпиляции большого проекта" (все эти тенденции практически нашли своё отражение в реализации виртуальной машины для языка Java). :grum:

[mineral]

;)
Не совсем. Для бизнес-приложений в самом деле использовались когда-то "генераторы кода" (и даже целое направление было - 4GL).
Только результат был - "не особенно хороший". Обычно вся совокупность проблем именовалась "нестабильно работающее приложение". В последнее время наблюдается немного другая тенденция - "большой проект" преобразуется в совокупность "взаимодействующих маленьких" и даже - "самоорганизующихся взаимодействующих маленьких" (это когда "задача" спрашивает - "у кого мне получить данные" , какая-то другая отвечает и т.д.
Очень похоже на "архитектуру Jini". SOAP - тоже придерживается этих принципов ). "Большие монолитные" практически "отжили свой срок" (по большому счёту их практически никогда и не существовало). Кроме того - желательно избавиться от необходимости "перекомпиляции большого проекта" (все эти тенденции практически нашли своё отражение в реализации виртуальной машины для языка Java). :grum:

Это не новость... Впрочем, что спорить... Все это рассуждения... Без студии - смерть компании... С конкуренцией не поспеет... От так...

А вообще, прикольно на ассемблере писать... Оптимизируешь, как хочешь... Хы... Долго... Ну и что ж... Зато прикольно!

Качество компилляторов Microsoft нынче - хы... На ассемблере тока и остается, что для embedded systems писать...

Нестабилити у меня не было... Надо просто знать тот продукт, в котором пишешь... Есть, конечно, и глюки... Они в любом софте есть... Но преимущества намного перевешивают глюки...

Можно, конечно, всегда быть критически настроенным... Но... Какой смысл? У меня позитивный подход... О!

Меня всегда прикалывали бои Юниксовцев и Виндоусовцев... Или Джававцев и Дотнетовцев... Или пиэйчпишников и аэспишников...

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

Короче, просто надо думать о проекте... Идеальных средств разработки и систем нет... Всегда есть компромиссы...

[mineral]

;)
Visual Express - не является системой управления проектом на самом деле (система управления проектом должна включать элементы верификации проекта, а есть ведь ещё и методы автоматизированной оптимизации проекта - потоков данных и т.д. Visual Studio в этом отношении просто не может "конкурировать" с какой-нибудь Rational Rose. Да и не должна. По большому счёту - Visual является интерактивной tutorial для студентов-первокурсников. Хотя с "аналогами" от Borland работать удобнее). Visual - там вообще звучит довольно "обманчиво".
Основная идея всех Visual "от Microsoft" сводится к тому - чтобы "спрятать ошибки в реализациях своих собственных библиотек классов".
:grum:
Не совсем. Для бизнес-приложений в самом деле использовались когда-то "генераторы кода" (и даже целое направление было - 4GL).
Только результат был - "не особенно хороший". Обычно вся совокупность проблем именовалась "нестабильно работающее приложение". В последнее время наблюдается немного другая тенденция - "большой проект" преобразуется в совокупность "взаимодействующих маленьких" и даже - "самоорганизующихся взаимодействующих маленьких" (это когда "задача" спрашивает - "у кого мне получить данные" , какая-то другая отвечает и т.д.
Очень похоже на "архитектуру Jini". SOAP - тоже придерживается этих принципов ). "Большие монолитные" практически "отжили свой срок" (по большому счёту их практически никогда и не существовало). Кроме того - желательно избавиться от необходимости "перекомпиляции большого проекта" (все эти тенденции практически нашли своё отражение в реализации виртуальной машины для языка Java). :grum:

Майк, я так понял, ты в режиме отрицания сейчас... Ты когда-нибудь использовал Rational Rose? Маленьким и средне-маленьким компаниям она нафиг не нужна... Слишком наворочено и слишком дорого...

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

Она нужна там, где она нужна... В основном, в огромных проектах... (что, тоже, не гарантирует успех... это всего лишь инструмент) Всему свое приминение...

Кстати, IBM, используя Rational Rose, года три назад завалил 4-миллиардный проект... То бишь, не завалил, а просто он стал неактуален... Время - деньги... Вот так... Все такое, принципы разработки и управление ею, теория и т.д. и т.п... это все хорошо, конечно... Но это все теория... На практике, к сожалению, приходится встречаться совершенно с другим... Это уже не университетский курс... Здесь надо зарабатывать деньги...

[crazy-mike]

Качество компилляторов Microsoft нынче - хы... На ассемблере тока и остается, что для embedded systems писать...
...

Традиционно плохое вообще-то "качество компиляторов" от Microsoft. ;)
(особенно это относится к их реализации языка C/++. Все нормальные люди - когда пишут на C/++ - стараются просто отключить оптимизацию , иначе приложение чаще всего просто не будет вообще работать).
:grum:
Кроме того - интепретация p-кода (при одном из уровней оптимизации) вызывает совсем другие "особенности распределения памяти" (не такие как в других случаях). Microsoft достаточно "подло" отклонялась и от стандарта c89 и от c99 в реализациях своих компиляторов. Из-за этого для создания переносимых систем приходилось инкапсулировать вызовы Microsoft-dependent функций внутри "своих". ;)

[mineral]

Традиционно плохое вообще-то "качество компиляторов" от Microsoft. ;)
(особенно это относится к их реализации языка C/++. Все нормальные люди - когда пишут на C/++ - стараются просто отключить оптимизацию , иначе приложение чаще всего просто не будет вообще работать).
:grum:
Кроме того - интепретация p-кода (при одном из уровней оптимизации) вызывает совсем другие "особенности распределения памяти" (не такие как в других случаях). Microsoft достаточно "подло" отклонялась и от стандарта c89 и от c99 в реализациях своих компиляторов. Из-за этого для создания переносимых систем приходилось инкапсулировать вызовы Microsoft-dependent функций внутри "своих". ;)

Я писал сложнейшие библиотеки для обработки графики в С++, компиллируя с оптимизацией... Все работало нормально... Natioal Geogrphic Maps, выпущенные в году 1998, использовали наши библиотеки... Лучший графический софт (по какой-то тематике) 1998 года были признаны...

Просто, писать надо чисто и правильно (включая дизайн)... Может, проблемы, о которых ты пишешь, и существуют... Тока я с ними не сталкивался...

А нарушение стандартов... Ну так что ж... Я принимаю все как есть... И все работает... Просто знать надо об этом...

Мне некогда заниматься теорией и стандартами компилляторов... Зато есть время продукт доставлять клиентам... Работает отлично... Зачем мне морочить голову тем, что не влияет на product delivery...

Ежели возникнет надобность, придется окунуться... Но драматизация деталей - это трата времени...

Наверное, с теоретической точки это важно, не спорю... Но на практике, для большинства разработчиков, это никакой роли не играет...

[mineral]

Я сейчас своих девелоперов гоняю здорово... Думают дизайн правильно сделали... Оптимизация и стабильность начинаются с дизайна... Иногда такой логики понаворотят... Хы...

[crazy-mike]

Я писал сложнейшие библиотеки для обработки графики в С++, компиллируя с оптимизацией... Все работало нормально... Natioal Geogrphic Maps, выпущенные в году 1998, использовали наши библиотеки... Лучший графический софт (по какой-то тематике) 1998 года были признаны...
Просто, писать надо чисто и правильно... ... Но на практике, для большинства разработчиков, это никакой роли не играет...

;)
Там как раз проблемы возникают при "портировании приложений". Просто классы связанные с реализацией фукций CUA внутри разных операционных систем (Win ME, Win XP, Win CE (Win Mobile)) - ведут себя "немного иначе". Из-за этого многие "обработчики событий" или вообще не срабатывают или , что намного хуже , срабатывают "не так". (Это не Open GL и не DirectX , а обычный CUA (в MFC)). Интересные вещи возникали при портировании кросс-платформных библиотек в исходных текстах (wxWidgets на платформу Microsoft C++ 7.0). Портирование конечно же сводилось к компиляции библиотеки. Только вот потом "работающее приложение" с её использованием получалось только при "строго определённых" настройках среды компиляции.
Работающая и скомпилированная в Borland C++ 5.5 программа - при перекомпиляции в Microsoft C++ 7.0 просто не работала (после перекомпиляции).

[mineral]

Никогда не использовал MFC... Весь пользовательский интерфейс писался на VB... Опять же, специфика... Сэкономили уйму времени....

Про Борланд я ничего не говорю... После 1995 года, я его не использовал... У MS есть свои расширения... Знать надо было, когда на Борланде писали... Планировать надо... Ну, и зачем на MS перепрыгнули в конце концов? Надо было на Борланде и заканчивать... Хы...

Я же говорю, надо знать продукт, на котором разрабатываешь... И несовместимости тоже желательно знать... Нет идеальных систем... Просто можно мириться с недостатками... И даже надо...

Вопросами портирования не занимался... Скоро будем писать код для Smart Phones, тады посмотрим... Но писать будем в C#... Предполжительно... Летом начнем разрабатывать стратегию, изучать инструменты....