Мне кажется, что производители средств работки ПО всех специально водят за нос.
Вот Microsoft создала офигенную среду VStudio, а средства взаимодействия с БД или тестирования так и остались на 0-м уровне.
Или в стандартных библиотеках есть никому не нужные компоненты табличек, дат и прочие.
С другими производителями почти то же стамое.
На практике сталкиваешься с другой стороной медали.
Как правило разработчики используют покупную библиотеку, пишут свои средства для упрощения работы с БД, строят свои системы багтрекинга (или опенсорс), организуют свои системы тестирования.
Если работаешь в крупной системе, Axapta например, то там многие операции взаимодействия с БД автоматизированы
Или Галакстика например, создала свое ядро РАНЕТ.
Плюс различные шаблоны разработываются для упрощения и стандартизации ГУИ.
Почему этих примитивных инструментов не делает Microsoft или другие?
Без ниж же прогать толком невозможно.
Получается на монстроидальных средствах работки только и можно, что кнопочки выводить, да трудоемко прогать
Или методом проб и ошибок подбирать сторонние компоеннты.
Re: Почему не создают нормальных средств разработки?
M>Дает тебе возможность заработать написав свои и продавая за огромные деньги ? M>Перефразирую , а почему ты этого не пишешь и не продаешь ?
По-моему понятно почему. Нет таких гигантских ресурсов и я же не разработчик VStudio.
Вопрос-то и задаю, так как качество средств сторонних разработчиков оставляет желать лучшего.
А технологии эти нужны для нормальной работки ПО.
Вот если бы они были в самом пакете разработки, то я или котора моглабы сконцентироваться на самой прикладно задаче,
а не париться с низким уровнем и изысками.
Re: Почему не создают нормальных средств разработки?
Здравствуйте, Бусел, Вы писали:
Б>Вот если бы они были в самом пакете разработки, то я или котора моглабы сконцентироваться на самой прикладно задаче, Б>а не париться с низким уровнем и изысками.
Если ВСЕ средства интегрировать в одно, то ты никогда его купить не сможешь. Да и интеграция всего в одно сверхсложная задача, которую и Microsoft не потянет.
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: Почему не создают нормальных средств разработки?
Здравствуйте, _Obelisk_, Вы писали:
_O_>Если ВСЕ средства интегрировать в одно, то ты никогда его купить не сможешь. Да и интеграция всего в одно сверхсложная задача, которую и Microsoft не потянет.
Да прям таки. Вот есть винда, типа ОС. А в неё интегрировано абсолютно всё: IE и WMP
Здравствуйте, _Obelisk_, Вы писали:
_O_>Если ВСЕ средства интегрировать в одно, то ты никогда его купить не сможешь. Да и интеграция всего в одно сверхсложная задача, которую и Microsoft не потянет.
Речь не идет об интеграции.
Речь и дет о минимальном джентельменском наборе.
Например, в VStudio работа с БД никак не упрощена в то время как существоет много способов стандартизировать сей рутинный труд.
Re[5]: Почему не создают нормальных средств разработки?
Б>Речь и дет о минимальном джентельменском наборе. Б>Например, в VStudio работа с БД никак не упрощена в то время как существоет много способов стандартизировать сей рутинный труд.
Работа с БД в Visual Studio (я так понял, речь об ADO.NET?) и так переусложнена до такой степени, что в более-менее приличном проекте половину приходится выкидывать и делать самому Оставляя только IDataReader.
Чем более "готовое" средство ты предложишь, тем меньшему числу разработчиков/проектов оно подойдет.
Чем больше будет MS тратить сил на всякие "полуфабрикаты", "упрощения ручного труда" и тп. — тем меньше сил у них останется на хорошую проработку низкоуровневых вещей — пусть уж лучше они это делают!
А вы лучше сами подумайте, как можете упростить и стандартизовать конкретно ваш рутинный труд.
Re[2]: Почему не создают нормальных средств разработки?
Здравствуйте, _pk_sly, Вы писали:
Б>>Вот Microsoft создала офигенную среду VStudio
__>чем же она, интересно, "офигенная"?
__>не ноутпад, конечно, но и конкурентов они догонять начали совсем недавно. __>... а потом стали опять отставать 8)
а у вас есть на примете достойный конкурент по возможностям отладки с++ кода?
Re[5]: Почему не создают нормальных средств разработки?
Здравствуйте, Бусел, Вы писали:
Б>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Если ВСЕ средства интегрировать в одно, то ты никогда его купить не сможешь. Да и интеграция всего в одно сверхсложная задача, которую и Microsoft не потянет.
Б>Речь не идет об интеграции. Б>Речь и дет о минимальном джентельменском наборе. Б>Например, в VStudio работа с БД никак не упрощена в то время как существоет много способов стандартизировать сей рутинный труд.
Здравствуйте, Бусел, Вы писали:
Б>Мне кажется, что производители средств работки ПО всех специально водят за нос. Б>Вот Microsoft создала офигенную среду VStudio, а средства взаимодействия с БД или тестирования так и остались на 0-м уровне.
А вот Jetbrains делает:
Java IDE, которая по праву считается лучшей среди Java IDE — IntelliJ IDEA;
intellisense-инструмент к MSVS, без которого работать с кодом практически невозможно (невозможно означает, что после того, как человек поработает с кодом на intellisense features, ему крайне тяжело становится работать без них) — Resharper.
А вот Eclipse Foundation (по сути IBM) развивает огромную серию проектов под общим названием Eclipse, в том числе и флагманский проект Eclipse SDK — Java IDE, которая сильно конкурирует с IntelliJ IDEA. К примеру, сейчас на Eclipse люди работают с кодом Java, C++, C#, Scala, Ruby, Groovy, PHP и etc — все благодаря проекту Equinox (реализация стандарта OSGi, грубо говоря, динамическая модульность), упрощающему добавление функционала.
Б>Или в стандартных библиотеках есть никому не нужные компоненты табличек, дат и прочие.
Вы про IDE или SDK, определитесь может?
Б>С другими производителями почти то же стамое.
Вранье.
Б>На практике сталкиваешься с другой стороной медали. Б>Как правило разработчики используют покупную библиотеку, пишут свои средства для упрощения работы с БД, строят свои системы багтрекинга (или опенсорс), организуют свои системы тестирования.
Если конкретно про MSVS, то попробуйте посмотреть самый дорогой ее вариант — Team Suit.
Б>Если работаешь в крупной системе, Axapta например, то там многие операции взаимодействия с БД автоматизированы Б>Или Галакстика например, создала свое ядро РАНЕТ. Б>Плюс различные шаблоны разработываются для упрощения и стандартизации ГУИ. Б>Почему этих примитивных инструментов не делает Microsoft или другие? Б>Без ниж же прогать толком невозможно.
Слишком сумбурно все, свалили в кучу претензии и к SDK, и к IDE — попробуй разгреби.
Б>Получается на монстроидальных средствах работки только и можно, что кнопочки выводить, да трудоемко прогать Б>Или методом проб и ошибок подбирать сторонние компоеннты.
Опять... какое отношение имеет IDE к набору компонентов в SDK?
Re[2]: Почему не создают нормальных средств разработки?
Здравствуйте, _pk_sly, Вы писали:
Б>>Вот Microsoft создала офигенную среду VStudio
__>чем же она, интересно, "офигенная"?
__>не ноутпад, конечно, но и конкурентов они догонять начали совсем недавно. __>... а потом стали опять отставать 8)
Да ну, а мужики-то не знают. Каких-таких конкурентов, например?
Re[3]: Почему не создают нормальных средств разработки?
R>Не смотрел Orcas, но MSVS2005 сильно не дотягивает по возможностям до других IDE (не в привязке к конкретной платформе .NET, а просто по функционалу).
Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ?
Re[5]: Почему не создают нормальных средств разработки?
Здравствуйте, dip_2000, Вы писали:
_>Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ?
Хм... приведу список того, что у меня есть в Eclipse SDK или встроенного, или фришного, и чего соответственно нет или является платным для MSVS2005:Intellisense-инструмент. В Eclipse SDK встроенный, а Resharper надо ставить отдельно, несмотря на то, что итак понятно, что такое средство нужно, что без него жутко неудобно, и он платный. Настройки. В MSVS гипермало вынесено в настройки. Система контроля версий. По интеграции с SVN: Sublipse бесплатный и многофункциональный, а VisualSVN платный и убогий. По локальному контролю версий: в MSVS вообще нет, а бывает очень удобно. Работа с проектами. Очень непонятна идеалогия решений (solutions) в MSVS, знаю, что MS в нее вкладывает, но на деле — это только палки в колеса. Почему я не могу работать одновременно с двумя solutions? Это в соответствии с идеалогией MS-ов абсолютно разные проекты, никоим образом не связанные, потому и разнесены. Но очень часто нужно заглянуть в старый проект, чтобы посмотреть, как делал там определенное место (память человеческая, знаете, короткая) — вот сейчас для этого приходится открывать два экземпляра MSVS, слава богу, что два монитора использую... иначе вообще было бы неудобно. Планирование. Task-и в MSVS примитивные до убогости. В Eclipse даже стандартные более пригодные (хотя тоже несерьезно все подобное), но в основном удобен в использовании плагин огромного отдельного проекта Mylyn, которым Eclipse Foundation хвастаются сейчас на каждом углу. Многопоточность ГИПа. В этом разделе уже как-то смеялись над сообщением IT по поводу статьи от команды MSVS про столпы параллелизма о том, что "де парни всех поучают, а у самих MSVS замирает при сборке". В Eclipse SDK же у меня порой выполняется параллельно несколько действий: фоновая сборка одного проекта, синхронизация с SVN другого, деплоймент третьего и т.п. — при этом я постоянно имею отклик от ГИПа, то есть не жду, а продолжаю работать. Тем паче в Eclipse SDK инкрементальная компиляция доведена до ума, ручной запуск сборки, в принципе, не требуется и к моменту запуска программы сборка практически всегда уже завершена. Производительность. Категорично не стану утверждать, с чем это связано и виновата ли сама MSVS в том... но на моей машине MSVS тормозит на порядок сильнее, нежели Eclipse SDK. Кстати, никто не знает, зачем моя MSVS при запуске каждого билда стучится на clr.microsoft.com (однажды в течении продолжительного времени)?И т.д. и т.п. На самом деле в MSVS просто нет того количества уже написанных плагинов, огромное количество которого есть для Eclipse. Найти бесплатный модуль для Eclipse, к примеру, по работе с базами данных, построению UML или любой другой не составляет труда — уже очень много (очень это означает, что количество MSVS Add-In-ов не идет ни в какое сравнение) накопленно.
Re[6]: Почему не создают нормальных средств разработки?
R>Хм... приведу список того, что у меня есть в Eclipse SDK или встроенного, или фришного, и чего соответственно нет или является платным для MSVS2005:Intellisense-инструмент. В Eclipse SDK встроенный, а Resharper надо ставить отдельно, несмотря на то, что итак понятно, что такое средство нужно, что без него жутко неудобно, и он платный.
Intellisense — в MS Visual Studio есть и для C++ и для С#. Да, сторонние средства его сильно улучшают (ReSharper и VisualAssist) — но и без них он есть.
R>Настройки. В MSVS гипермало вынесено в настройки.
Чего не хватает?? Там и так не сыщешь нужного, за деревьями леса...
R>Система контроля версий. По интеграции с SVN: Sublipse бесплатный и многофункциональный, а VisualSVN платный и убогий. По локальному контролю версий: в MSVS вообще нет, а бывает очень удобно.
Встроенная в MSVC VCS — это Visual Source Safe. С ней она работает сразу. Subclipse теперь входит в поставку Eclipse? Раньше вроде бы не входил. В поставке вроде бы только плагин для работы с CVS идёт, нет?
R>Работа с проектами. Очень непонятна идеалогия решений (solutions) в MSVS, знаю, что MS в нее вкладывает, но на деле — это только палки в колеса. Почему я не могу работать одновременно с двумя solutions? Это в соответствии с идеалогией MS-ов абсолютно разные проекты, никоим образом не связанные, потому и разнесены. Но очень часто нужно заглянуть в старый проект, чтобы посмотреть, как делал там определенное место (память человеческая, знаете, короткая) — вот сейчас для этого приходится открывать два экземпляра MSVS, слава богу, что два монитора использую... иначе вообще было бы неудобно.
Solution — это не проект. Проект — это Project. Открывай два проекта в одном Solution и работай на здоровье.
R>Планирование. Task-и в MSVS примитивные до убогости. В Eclipse даже стандартные более пригодные (хотя тоже несерьезно все подобное), но в основном удобен в использовании плагин огромного отдельного проекта Mylyn, которым Eclipse Foundation хвастаются сейчас на каждом углу.
Не знаю, никогда таски не использовал ни в одном IDE. Для тасков скорее нужны системы управления проектом. Неплохо, наверное, если они интегрированы в IDE — но мне и без этого живётся неплохо.
R>Многопоточность ГИПа. В этом разделе уже как-то смеялись над сообщением IT по поводу статьи от команды MSVS про столпы параллелизма о том, что "де парни всех поучают, а у самих MSVS замирает при сборке". В Eclipse SDK же у меня порой выполняется параллельно несколько действий: фоновая сборка одного проекта, синхронизация с SVN другого, деплоймент третьего и т.п. — при этом я постоянно имею отклик от ГИПа, то есть не жду, а продолжаю работать. Тем паче в Eclipse SDK инкрементальная компиляция доведена до ума, ручной запуск сборки, в принципе, не требуется и к моменту запуска программы сборка практически всегда уже завершена.
MSVC замирает при сборке? Первый раз слышу.
R>Производительность. Категорично не стану утверждать, с чем это связано и виновата ли сама MSVS в том... но на моей машине MSVS тормозит на порядок сильнее, нежели Eclipse SDK. Кстати, никто не знает, зачем моя MSVS при запуске каждого билда стучится на clr.microsoft.com (однажды в течении продолжительного времени)?И т.д. и т.п. На самом деле в MSVS просто нет того количества уже написанных плагинов, огромное количество которого есть для Eclipse. Найти бесплатный модуль для Eclipse, к примеру, по работе с базами данных, построению UML или любой другой не составляет труда — уже очень много (очень это означает, что количество MSVS Add-In-ов не идет ни в какое сравнение) накопленно.
В Eclipse работал только с CDT — могу смело утверждать что втыкает она на С++ проектах намного сильнее чем Visual Studio 2003.
Как человек который работает в основном с С++ могу сказать — связку MSVC + Visual Assist по удобству навигации по коду, поддержки Intellisense и т.п. удобностям Eclipse + CDT ещё очень долго не догонит. Насчёт других языков —
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[6]: Почему не создают нормальных средств разработки?
ясно, т.е. вы не знаете как с ним работать, и плюс еще хотите что бы оно было бесплатным
Я вот сейчас пробую после VS научиться использовать Eclipse(как IDE для разработки на винде под хитрые Linux's), и у меня в нем то же мало что получается Только вот делать вывод на основе этого, что IDE плохой я не буду.
Про бесплатность — ничего говорить не буду
Re[7]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>Intellisense — в MS Visual Studio есть и для C++ и для С#. Да, сторонние средства его сильно улучшают (ReSharper и VisualAssist) — но и без них он есть.
Знаю, но то, что есть, по сравнению с существующими на рынке решениями — как будто его и нет. MS чуть не самый крупный софтверный вендор, не кошерно ему сие.
L>Чего не хватает?? Там и так не сыщешь нужного, за деревьями леса...
Многого. В Eclipse SDK намного больше настроек.
L>Встроенная в MSVC VCS — это Visual Source Safe. С ней она работает сразу. Subclipse теперь входит в поставку Eclipse? Раньше вроде бы не входил. В поставке вроде бы только плагин для работы с CVS идёт, нет?
Sublipse не входит в Eclipse SDK Classic, поддержка CVS — да, входит.
L>Solution — это не проект. Проект — это Project. Открывай два проекта в одном Solution и работай на здоровье.
Если бы вы внимательно прочитали, то поняли бы, в чем претензия. Если пихать все-все проекты в один solution, то, во-первых, боюсь, все умрет при определенном количестве проектов (да-да, знаю, их, конечно же, можно выгружать внутри solution, но см. "во-вторых"), а, во-вторых, таким образом вообще непонятно, что есть solution и на кой он нужен. Репозиторий проектов? Но MS же вкладывают иной смысл в него. Да и так бы по жизни хватило бы и одного репозитория с переключением на другие в настройках IDE.
L>Не знаю, никогда таски не использовал ни в одном IDE. Для тасков скорее нужны системы управления проектом. Неплохо, наверное, если они интегрированы в IDE — но мне и без этого живётся неплохо.
Кому как, мне живется без этого плохо. Mylyn же как раз и есть средство интеграции с СУПами.
L>MSVC замирает при сборке? Первый раз слышу.
Да. Re: Столпы параллелизма — The Pillars of Concurrency
L>В Eclipse работал только с CDT — могу смело утверждать что втыкает она на С++ проектах намного сильнее чем Visual Studio 2003. L>Как человек который работает в основном с С++ могу сказать — связку MSVC + Visual Assist по удобству навигации по коду, поддержки Intellisense и т.п. удобностям Eclipse + CDT ещё очень долго не догонит. Насчёт других языков —
Возможно, не спорю, с CDT не работал.
Re[7]: Почему не создают нормальных средств разработки?
Здравствуйте, dip_2000, Вы писали:
_>ясно, т.е. вы не знаете как с ним работать,
Не знаю, что вам тут ясно и почему вы делаете такие выводы.
_>и плюс еще хотите что бы оно было бесплатным
Во-первых, бесплатность, вообще говоря, далеко не минус. Во-вторых, я и мои работодатели готовы платить деньги, только, вот знаете, привереды мы, хотим, чтобы за свои деньги мы получали качественный продукт.
_>Я вот сейчас пробую после VS научиться использовать Eclipse(как IDE для разработки на винде под хитрые Linux's), и у меня в нем то же мало что получается Только вот делать вывод на основе этого, что IDE плохой я не буду.
Вот поработате несколько лет на другой платформе, потом приходите и поговорим. Намекать на мою предвзятость некорректно: с Java работаю порядка 6 лет, но и .NET-ом уже занимаюсь плотно больше 2 лет — если я вижу, что в Eclipse SDK я мог сделать нечто, что не могу сделать в MSVS (не в платформе, не в языке — здесь может просто проявляться различие самих платформ программирования, а именно тупые рутинные действия, смежные кодированию), то... Выше привел достаточно на мой взгляд объективные различия, если есть что сказать по существу, добро пожаловать, если так пофилософствовать о присущем человеку субъективизме и склонности к привыканию к чему-либо, то не по адресу.
_>Про бесплатность — ничего говорить не буду
И не надо.
Re[8]: Почему не создают нормальных средств разработки?
Здравствуйте, rsn81, Вы писали:
_>>ясно, т.е. вы не знаете как с ним работать, R>Не знаю, что вам тут ясно и почему вы делаете такие выводы.
Не воспринимайте за личный наезд Это совсем не он Просто в Вашем посте видно, что вы не владеете возможностями которые предоставляет VS(так же как и я Eclips ) — одни проекты/солюшены чего стоят
_>>и плюс еще хотите что бы оно было бесплатным R>Во-первых, бесплатность, вообще говоря, далеко не минус. Во-вторых, я и мои работодатели готовы платить деньги, только, вот знаете, привереды мы, хотим, чтобы за свои деньги мы получали качественный продукт.
Да. Это не минус. Откуда у вас в случае бесплатного продукта вы получите качественный продукт не понятно. Но дальше — холливар
_>>Я вот сейчас пробую после VS научиться использовать Eclipse(как IDE для разработки на винде под хитрые Linux's), и у меня в нем то же мало что получается Только вот делать вывод на основе этого, что IDE плохой я не буду. R>Вот поработате несколько лет на другой платформе, потом приходите и поговорим. Намекать на мою предвзятость некорректно: с Java работаю порядка 6 лет, но и .NET-ом уже занимаюсь плотно больше 2 лет — если я вижу, что в Eclipse SDK я мог сделать нечто, что не могу сделать в MSVS (не в платформе, не в языке — здесь может просто проявляться различие самих платформ программирования, а именно тупые рутинные действия, смежные кодированию), то... Выше привел достаточно на мой взгляд объективные различия, если есть что сказать по существу, добро пожаловать, если так пофилософствовать о присущем человеку субъективизме и склонности к привыканию к чему-либо, то не по адресу.
Я его пытаюсь использовать для с/с++ разработки. Так что это все не совсем то, и не совсем о том. Я сравнение провожу как с++ программист, IDE которые могут работать с с++ проектами.
Re[8]: Почему не создают нормальных средств разработки?
L>>Solution — это не проект. Проект — это Project. Открывай два проекта в одном Solution и работай на здоровье. R>Если бы вы внимательно прочитали, то поняли бы, в чем претензия. Если пихать все-все проекты в один solution, то, во-первых, боюсь, все умрет при определенном количестве проектов (да-да, знаю, их, конечно же, можно выгружать внутри solution, но см. "во-вторых"), а, во-вторых, таким образом вообще непонятно, что есть solution и на кой он нужен. Репозиторий проектов? Но MS же вкладывают иной смысл в него. Да и так бы по жизни хватило бы и одного репозитория с переключением на другие в настройках IDE.
На самом деле проекты и солюшны — это способ борьбы со сложностью систем
То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций. Очень удобно когда система у тебя разнородная — к примеру — проект состоит из части для PC, Pocket и Web-части. Тогда каждая часть билдится своим project-ом (или несколькими), но для каждого девелопера можно иметь свой solution (или несколько), где выделены те проекты которые ему нужны + общий solution для всего чего можно. До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[9]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>На самом деле проекты и солюшны — это способ борьбы со сложностью систем
Оно понятно, не хватает только одного: возможность открытия нескольких solutions или то, что вы предположили — их вложенность.
L>То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций. Очень удобно когда система у тебя разнородная — к примеру — проект состоит из части для PC, Pocket и Web-части. Тогда каждая часть билдится своим project-ом (или несколькими), но для каждого девелопера можно иметь свой solution (или несколько), где выделены те проекты которые ему нужны + общий solution для всего чего можно. До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Это все понятно. Я же говорил только про то, что нужно бывает только одним глазком зыркнуть в старый solution, который никак не связан и не будет связан с текущим, чтобы просто посмотреть один-два метода или даже класса, быть может даже скопировать их. Простое действие же ж. Только ради этого добавлять проекты в решение, хм, не очень интуитивно...
L>Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions.
Ага, в принципе, можно Unload Project делать, оно понятно.
Re[10]: Почему не создают нормальных средств разработки?
Здравствуйте, rsn81, Вы писали:
L>>Кстати, насчёт проектов в Solution — на 2003-й студии вполне сносно работается с сотней-другой проектов. И, кстати, недавно вышел апдейт на новые студии как раз для ускорения работы с большими Solutions. R>Ага, в принципе, можно Unload Project делать, оно понятно.
Зачем Unload? у меня на данный момен загружено 130 проектов, и ничего страшного не происходит. Потребности выгружать проекты не ощущаю.
... << RSDN@Home 1.2.0 alpha rev. 783>>
Re[5]: Почему не создают нормальных средств разработки?
Здравствуйте, Бусел, Вы писали:
Б>Например, в VStudio работа с БД никак не упрощена в то время как существоет много способов стандартизировать сей рутинный труд.
Что подразумевается под упрощением работы с БД? Если создание схемы, то есть VSDB, если деплоймент, то та же VSDB и Team Suite for System Administrators, если доступ к данным, то ADO.NET, если OR/M, то Linq to SQL и Linq to Entities, если упрощение создания каких то настройщиков и дизайнеров, то DSL Tools в составе VS SDK. Ну м т.д.
Left2 wrote: > В Eclipse работал только с CDT — могу смело утверждать что втыкает она > на С++ проектах намного сильнее чем Visual Studio 2003.
Ну CDT постепенно становится лучше. Хотя развиваться ему еще долго.
> Как человек который работает в основном с С++ могу сказать — связку MSVC > + Visual Assist по удобству навигации по коду, поддержки Intellisense и > т.п. удобностям Eclipse + CDT ещё очень долго не догонит. Насчёт других > языков —
Просто для С++ нормально ничего сделать нельзя. Такой уж язык...
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[6]: Почему не создают нормальных средств разработки?
rsn81,
_>>Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ?
Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
_>>>Ну вы не могли бы описать, чего на Ваш взгляд не хватает в VS ? LCR>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
Eclipse есть и for c++ developers. Да и студию человек сравнивает не только по с++, у него .Net Опыт есть
Re[7]: Почему не создают нормальных средств разработки?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования).
C++ серьезно вообще не занимаюсь (здесь даже ничего сказать особенного не могу), говорил про MSVS С# (without Resharper) vs Eclipse SDK Java (with JDT) — у этих языков-то синтаксис одной ступени сложности.
Re[8]: Почему не создают нормальных средств разработки?
rsn81,
LCR>>Сравнивать IDE под джаву и под C++ — это как бы сказать... нечестно. В C++ много труднее сделать интеллисенс, рефакторинг и компилятор реального времени, особенно когда исходник некорректный (например, в середине процесса редактирования). R>C++ серьезно вообще не занимаюсь (здесь даже ничего сказать особенного не могу), говорил про MSVS С# (without Resharper) vs Eclipse SDK Java (with JDT) — у этих языков-то синтаксис одной ступени сложности.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ага, понял. Токо почему "without Resharper"?
Потому что с одной стороны модуль JDT поставляемый с бесплатной Eclipse SDK Classic в коробке содержит intellisense, а платный MSVS2005 в коробке Resharper не содержит. От покупного продукта, тем паче от такого монстра как MS, хотелось бы большего... хотя бы в коробке Team Suit. Вы представьте простую гипотетическую ситуацию: с горем пополам обосновываешь начальству необходимость приобретения лицензии на MSVS (хотя оно все норовит с едкой ухмылкой спросить: "Ты чего, кряк сам найти не можешь, да?"), а потом приходится просить уже мизерную сумму на жизненно необходимый Add-In к ней, тут уже вопрос будет задан точно в лоб: "Так какого мы тогда лешего тратили деньги на прошлое приобретение, если оно тебя так сильно не устраивает, а?"
Re[8]: Почему не создают нормальных средств разработки?
Здравствуйте, rsn81, Вы писали:
L>>Чего не хватает?? Там и так не сыщешь нужного, за деревьями леса... R>Многого. В Eclipse SDK намного больше настроек.
Армяне лучше чем грузины. Чем? Чем грузины!(с)
Что конкретно-то вам не удаётся настроить в VS?
Re[9]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>То есть, project — описание как собрать один target (EXE, Dll, MSI), причём в различных конфигурациях (набор которых может отличаться от проекта к проекту). Solution позволяет описывать зависимости между project-ами и между их конфигурациями. То есть, грубо говоря, solution завязан только на имя проекта и на имена его конфигураций.
Это "грубо говоря" — а вообще-то это не так — в этом месте определенная и вполне достаточная гибкость имеется: даже через IDE можно настроить чтобы Solution Target ("Configuration") собирал Project Targets ("Configuration"s) хоть в шахматном порядке — к тому же легко сделать новый что тот, что другой и подключается в солюшин именно "конфигурация", а не просто "проект по имени". Так что с этим все впорядке — просто "по умолчанию" это сделано настолько удобно, что редко кто на самом деле меняет "классический" порядок включения прожект билдов. Прошу прощения что постянно все называю по-разному.
L>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions.
Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
Голь на выдумку хитра, однако...
Re[10]: Почему не создают нормальных средств разработки?
L>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
Голь на выдумку хитра, однако...
Re[12]: Почему не создают нормальных средств разработки?
TL>Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
Ну а эту lib-у собирать — из другого Solution? Не очень удобно — удобно когда каждый Solution делает сборку конечного target-а (Exe или Dll, или ещё чего-нить) от начала до конца.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[13]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
TL>>Как насчет того, чтобы не включать проект базовых библиотек в солюшин? Т.е. выполнять сборку (линковку) не по зависимостям проектов в солюшине, а прямой линковкой .lib? Какие недостатки такого метода на ваш вгляд?
L>Ну а эту lib-у собирать — из другого Solution? Не очень удобно — удобно когда каждый Solution делает сборку конечного target-а (Exe или Dll, или ещё чего-нить) от начала до конца.
Мало того: собрал один раз — и больше не пересобирать без необходимости. Да и код либы тоже можно всем подряд не раздавать, а только заголовки — ну и код, конечно, по мере необходимости.
P.S. Речь идет о проектах C++ объема средних и выше.
Голь на выдумку хитра, однако...
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>>>... До идеала, ИМХО, этой системе не хватает только возможности иметь вложеные solutions. TL>>Честно говоря, лично не сталкивался с такой потребностью. Можно спросить "зачем надо?" — какие будут прецеденты использования у такой функции?
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Solution folder как раз для группировки проектов и существует.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[10]: Почему не создают нормальных средств разработки?
The Lex wrote: > Это "грубо говоря" — а вообще-то это не так — в этом месте определенная > и вполне достаточная гибкость имеется: даже через IDE можно настроить > чтобы Solution Target ("Configuration") собирал Project Targets > ("Configuration"s) хоть в шахматном порядке — к тому же легко сделать > новый что тот, что другой и подключается в солюшин именно > "конфигурация", а не просто "проект по имени".
Solution'ы в понятии Студии — мастдай. Гибкости очень сильно как раз не
хватает.
Например, ОЧЕНЬ ОЧЕНЬ неудобно управлять так 5-10 разными конфигурациями
проекта (32 bit и 64 bit, каждая в debug и release и еще static/dynamic
для библиотек).
Мне сейчас нравится как это сделано в Boost.Build — можно наследовать
настройки или автоматически подстраивать в зависимости от требований.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[11]: Почему не создают нормальных средств разработки?
C>Мне сейчас нравится как это сделано в Boost.Build — можно наследовать C>настройки или автоматически подстраивать в зависимости от требований.
В 2005-й студии тоже можно наследовать настройки (для проектов). Правда, там таааакой неудобный user interface (ну или по крайней мере мне так показалось)... Но зато никто не мешает напрямую править XML-файлы
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, Left2, Вы писали:
L>К примеру, есть большая система, из десятка exe-файлов, и трёх десятков библиотек (зависимых друг от друга) из которых эти exe-файлы собираются. Иметь всё в одном solution неудобно — много лишнего перед глазами. А иметь всё в нескольких solutions — означает настраивать зависимости проектов друг от друга в каждом из solutions отдельно. Вложенные solutions тут бы мне здорово помогли.
Solution — это просто костыль. На самом деле, нужна просто вложенная иерархия проектов. Еще может иметь смысл понятие workspace, куда можно добавить проекты, которые не связаны непосредственно с главным проектом, но нужны чтобы подсмотреть в них какие-то детали, например.
Re[12]: Почему не создают нормальных средств разработки?
Left2 wrote: > C>Мне сейчас нравится как это сделано в Boost.Build — можно наследовать > C>настройки или автоматически подстраивать в зависимости от требований. > В 2005-й студии тоже можно наследовать настройки (для проектов). Правда, > там таааакой неудобный user interface (ну или по крайней мере мне так > показалось)... Но зато никто не мешает напрямую править XML-файлы
От редактирования XML-файлов остается сделать еще один шаг — и понять,
что нормальные build-файлы редактировать удобнее Ну или взять CMake,
который умеет генерировать Solution'ы для MSVS.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[13]: Почему не создают нормальных средств разработки?
C>Ну или взять CMake, который умеет генерировать Solution'ы для MSVS.
А есть положительный опыт работы с ним? Так сказать, success story? А то что-то крупные кроссплатформенные проекты на С/C++ что-то не спешат на него переезжать. Можешь хотя бы в паре слов разрисовать плюсы-минусы? Спасибо заранее.
... << RSDN@Home 1.2.0 alpha rev. 717>>
Re[13]: Почему не создают нормальных средств разработки?
Здравствуйте, Cyberax, Вы писали:
C>От редактирования XML-файлов остается сделать еще один шаг — и понять, C>что нормальные build-файлы редактировать удобнее Ну или взять CMake, C>который умеет генерировать Solution'ы для MSVS.
Можно еще шажок сделать и взять что то подобное scons
Re[14]: Почему не создают нормальных средств разработки?
Left2 wrote: > C>Ну или взять CMake, который умеет генерировать Solution'ы для MSVS. > А есть положительный опыт работы с ним? Так сказать, success story? А то > что-то крупные кроссплатформенные проекты на С/C++ что-то не спешат на > него переезжать. Можешь хотя бы в паре слов разрисовать плюсы-минусы?
На CMake переехал весь проект KDE. Причем по отзывам разработчиков — им
он ОЧЕНЬ понравился.
С CMake я лично сталкивался при работе с VTK (Visualization Toolkit).
Ничего криминального там не заметил — все работало вполне прилично.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[14]: Почему не создают нормальных средств разработки?
FR wrote: > C>От редактирования XML-файлов остается сделать еще один шаг — и понять, > C>что нормальные build-файлы редактировать удобнее Ну или взять CMake, > C>который умеет генерировать Solution'ы для MSVS. > Можно еще шажок сделать и взять что то подобное scons
Про SCons особо много сказать не могу. Я его немного смотрел — выглядит
круто, особенно для сложной логики сборки проектов (кстати, именно его
использовали для сборки Quake3).
Здравствуйте, Cyberax, Вы писали:
C>Про SCons особо много сказать не могу. Я его немного смотрел — выглядит C>круто, особенно для сложной логики сборки проектов (кстати, именно его C>использовали для сборки Quake3).
Уточню маленько: для сборки Quake3 разработчиками ID Software использовался Cons — предшественник SCons, написанный на перле. SCons используется в Doom3 SDK и в icculus.org Quake3.
Re[15]: Почему не создают нормальных средств разработки?
Здравствуйте, Cyberax, Вы писали:
C>Есть еще подобный SCons'у проект, называется Waf: C>http://freehackers.org/~tnagy/waf.html C>http://code.google.com/p/waf/ C>Я его тоже использую в некоторых проектах — он работает намного быстрее C>SCons'а (после того, как я слегка его попинал).
Посмотрел, по первому впечатлению, гораздо менее декларативный чем scons.
Re[16]: Почему не создают нормальных средств разработки?
Здравствуйте, FR, Вы писали:
C>>Есть еще подобный SCons'у проект, называется Waf: C>>http://freehackers.org/~tnagy/waf.html C>>http://code.google.com/p/waf/ C>>Я его тоже использую в некоторых проектах — он работает намного быстрее C>>SCons'а (после того, как я слегка его попинал).
FR>Посмотрел, по первому впечатлению, гораздо менее декларативный чем scons.
Посмотри на Mxx_ru (документация в виде PDF здесь).
По декларативности Ruby дает фору Python-у.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Почему не создают нормальных средств разработки?
Здравствуйте, FR, Вы писали:
C>>Я его тоже использую в некоторых проектах — он работает намного быстрее C>>SCons'а (после того, как я слегка его попинал). FR>Посмотрел, по первому впечатлению, гораздо менее декларативный чем scons.
Из моего опыта: декларативность нафиг не нужна в сборщиках проектов. Нужно только нормальное вычисление зависимостей.
Sapienti sat!
Re[17]: Почему не создают нормальных средств разработки?
Здравствуйте, Cyberax, Вы писали:
FR>>Посмотрел, по первому впечатлению, гораздо менее декларативный чем scons. C>Из моего опыта: декларативность нафиг не нужна в сборщиках проектов. Нужно только нормальное вычисление зависимостей.
Кому как, без декларативности хватит просто библиотечки для питона умеющей искать зависитмости.
Re[18]: Почему не создают нормальных средств разработки?
Здравствуйте, FR, Вы писали:
FR>>>Посмотрел, по первому впечатлению, гораздо менее декларативный чем scons. C>>Из моего опыта: декларативность нафиг не нужна в сборщиках проектов. Нужно только нормальное вычисление зависимостей. FR>Кому как, без декларативности хватит просто библиотечки для питона умеющей искать зависитмости.
Нет, еще нужен планировщик (чтобы параллельно строить), куча утиллит, подключалки для разных инструментов и т.п. Это совсем немало.
Sapienti sat!
Re[9]: Почему не создают нормальных средств разработки?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>>Что конкретно-то вам не удаётся настроить в VS?
J>поиск/замена по регэкспам perl5. То, что в студии — отстойнейший маздай.
File -> New project -> Other project types -> Extensibility -> Visual Studio Add-in
Напишите. Там несложно, на три часа неторопливой работы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[11]: Почему не создают нормальных средств разработки?
Здравствуйте, denisio_mcp, Вы писали:
_>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>>>Что конкретно-то вам не удаётся настроить в VS?
J>>поиск/замена по регэкспам perl5. То, что в студии — отстойнейший маздай.
_>File -> New project -> Other project types -> Extensibility -> Visual Studio Add-in _>Напишите. Там несложно, на три часа неторопливой работы.
ага, и еще неделю на разобраться в потрохах студии...
сомневаюсь, что человек, который в жизни ничего для студии не писал, напишет такой плагин за 3 часа
Здравствуйте, jazzer, Вы писали:
J>ага, и еще неделю на разобраться в потрохах студии...
В потрохах не надо. Для такого плагина automation студийного хватит за глаза, а он простой как 3 копейки.
J>сомневаюсь, что человек, который в жизни ничего для студии не писал, напишет такой плагин за 3 часа
Такой напишет.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Left2, Вы писали:
YKU>>>Что конкретно-то вам не удаётся настроить в VS? J>>поиск/замена по регэкспам perl5. То, что в студии — отстойнейший маздай.
L>А какие преимущества у перловых регэкспов перед студийными?
да просто фич больше.
например, из всех "заглядываний" в студии есть только negative look-ahead.
или выборочный матчинг с кейсом/без кейса, или многострочный матчинг, или условный матчинг — всего этого нету.
) — одни проекты/солюшены чего стоят 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
