OberonCore

Волею судьбы выпало мне поучаствовать в одном небольшом веб проекте на ASP.NET.

Общее впечатление - майкрософт органически не способна делать простые инструменты Я сравниваю с тем, что использую при разработке на ББ - бесплатные и открытые продукты, хотя не так богаты на свистоперделки, однако куда удобнее и проще в использовании.

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

Скорость разработки на ББ примерно такая же (при наличии готовых компонентов, конечно же).

Так что сила майнстрима, я делаю вывод, только в количестве готовых к употреблению компонентов. Такие факторы, как удобство работы (см. интеллисенс), скорость девелопинга сами по себе, без набора "Юный Программист" - миф. Сложность и богатая функциональность инструментария - это вид вендор-локинга.

Такие дела.

Спасибо.
Важно иметь свидетельства, которые удобно предъявлять студентам и проч.

Мне отдельно понравилось замечание про помогальники:
Объясняет, почему такой, хм, латратус поднимают "профессионалы" по их поводу, встречаясь с ББ.
Они, выходит, привыкли, что без них разработчик "слеп".
Интересно.

Да, к примеру, полная квалификация имени, принятая в обероне. Простейшим образом облегчает восприятие. Удлиняет "словесность", но читать легче.

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

Да много всего, что и говорить. Но по себе скажу - погоды эти полезности, вроде бы, не делают, а новичка только смущают.

Не так давно трогал код на Турбо Паскале из нескольких файлов.
Бросил -- задолбался рыскать где что определено.

Удивляюсь: эта проблема известна несколько десятков лет...

Типичная оптимизация не там, где надо, порождающая сложность

Это, наверное, от изобилия денежных средств, всосанных американской экономикой со всего мира. Интересно, как будут обстоять дела после кризисной усушки.

Иван Кузьмицкий
Объективности ради стоит отметить, что ваше мнение - мнение неопытного пользователя.
Реально студия устроена так, что можно пользовать те фичи, которые реально нужны именно вам, а остальные просто не мешают.

По поводу "нельзя без подсказок" - извините, но это полная чушь. Это всего-лишь следствие того, что у вас глаз не набит, вы привыкли к инструменту с другой идеологией, вот и всё. Тоже самое я могу сказать и про ББ, когда только начинал с ним знакомится. Извините, но в КП тоже нельзя бросить взгляд на исходник, и мгновенно понять суть. Среда разработки тут вообще не причём. Это не более чем вопрос опыта.

Если уж и сравнивать объективно студию и бб как среды разработки и продакшена, то вопрос только в том, сколько вещей позволяет автоматизировать студия, а сколько бб. Так вот студия это ворд, а бб это блокнот. Чтобы понять эту разницу, попробуйте сделать рефакторинг проекта в студии, и в бб.

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

ПС А микрософт действительно не делает простые инструменты. Но не потому, что неспособна. Подозреваю, это у них такой маркетинг. Сложный инструмент дополнительно тянет за собой всякие обучающие программы, курсы, экзамены, и прочий профит $

Пока что дико мешают. Это поведение "по умолчанию". Особенно достаёт подсказка по параметрам метода, которая постоянно меняет свой размер и положение. Глаза банально устают.

Неймспейс определяете по запаху?


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

А надо ли? Вот в чём вопрос.

Как-то так получается, что рефакторинг на КП практически не нужен.

Маркетинг, да. А ещё вид вендор-локинга. К простому инструменту просто привыкнуть и просто отвыкнуть. А со сложного инструмента просто так не сойдёшь.

Вот меня тоже раздражают всякие подсказки. Они нужны только на начальном этапе, когда еще многое "не в пальцах". А потом, когда руки и голова уже сами знают, что делать - это только мешает.

Я аналогично при программировании на Турбо С++ в 92-м году проклинал разработчиков по той же причине...
И именно тогда впервые задумался о том, какая должна быть интегрированная среда...

Согласен о сравнении ворда и блокнота. Но как заметил еще Михаил Донской, ворд мне навязывают. Хотя мне очень часто достаточно блокнота.
Полностью согласен с ПС - потому и навязывают, чтобы создать спрос и доить пользователей. .

У оппонентов путаница: надо различать "понять смысл" и "понять структуру связей -- что где определено и т.п.".
Второе очень важно даже без первого.
И именно по второму пункту претензии.

Вы упустили суть: вопрос в языке и возможности понять любой исходник (не мгновенно). В языке без обязательной полной квалификации либо Вы лопатите весь набор исходников в поисках, либо это делает среда, и никакой опыт тут не помошник. В языке с обязательной полной квалификацией необходимости лопатить не возникает.
Сравнение не корректно. Блокнот не расширяем. Компонентная же среда позволяет автоматизировать всё что нужно. Вопрос в подборке/наличии нужных компонентов.

В студии немного работал. К общим впечатлениям тов. Кузьмицкого присоединяюсь. Но проблема не конкретно студии, а общего подхода к построению интерфейса (визарды и прочие обильные навороты, когда глаза у новичка в кучу и мозг в шоке). Примеров много кроме студии. Тот же ворд. Или ёпен офис.

Спасибо, важно.

Важно ещё и в целях "понять, как делается исходник"... напр., чтобы изложить это понимание... и/или определить иное представление. Здесь-то и рулит это:
На Обероне можно (действительно не мгновенно... особенно "предметнику" ) понять связи. А вот понять "мейнстримное"... попробовал человек - и вот результат... не знаю, закончилось ли дело чем-то?..
Или вот как решается этот вопрос: - см. этот пост. Вот такая "вижуал-студия"...

Вот-вот, "где что определено" не придется долго искать, если определения будут вынесены из текста программы в таблицы, связанные с соответствующими процедурами. На одной панели видишь исполнимую часть процедуры (алгоритм), а на соседней - таблицу используемых в ней переменных (включая формальные параметры процедуры) и т.п.

На самом деле, в нормальной процедуре не так уж и много локальных переменных. Обычно она вполне хорошо обозрима и понимаема. К тому же уровень современных ИДЕ впечатляет своей "интеллектуальностью", когда за тебя чуть-ли не весь код пишется.

Я упомянул обо ВСЕХ используемых в процедуре переменных, а не только о локальных. Плюсы табличного представления объявлений не только в лучшей обозримости и понимаемости, но и в возможности быстрой (пере)настройки атрибутов переменных, отсроченного определения примененных идентификаторов, в предотвращении и лучшей локализации ошибок, в возможности добавления объемных контекстных комментариев (с гиперссылками), интеграции со "справкой", в возможности использования в качестве "палитры" для вставки идентификаторов в исполнимую часть программы, для выделения вхождений и т.д. То есть, это инструмент для рефакторинга (и для соответствующих по масштабу программ).

Пожалуйста не путайте среду разработки и язык программирования. Необязательность явных квалификаций нэймспейсов это особенность си шарпа, а не студии. Если писать на компонентном паскале в студии, то яная квалификация также будет требоваться, как и в бб. Это требование языка, а не среды разработки. Поэтому я не согласен с этим пунктом "недостатков" студии. Я ж говорю, студия тут ни при чём.


Я студию не защищаю, просто хотелось бы объективности. Оффтопик: структуру связей в си шарпе без явной квалификации нэймспейсов действительно понять сложнее, чем в кп. Это бесспорно.


Кажется, студия тоже расширяема. Конечно, не так просто, как бб, но всё же. Выносим расширяемость за скобки, и сравниваем.


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

Раз уж тему подняли, найдётся тот, кто сможет составить табличку с плюсами\минусами студии и бб для конкретных применений?

Так это уже есть. И не только переменных, но и доступных функциях и т.п. Особых плюсов, тем более именно в табличном представлении нет. Более того, посторонняя таблица с боку/верху/низу будет отвлекать внимание. Другое дело существующая сейчас контекстная подсказка. В том числе с гиперссылками. Один клик по переменной и вы у её объявления, Клик на объявлении и вы у объявления её типа.

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

Года четыре назад пришлось перейти с гораздо более лучшего борландовского "C# Builder" на калечную микрософтовскую студию. Сначала плевался, потом привык. Вот представьте себе, я привык к Студии. Больше не жу-жу. Читать флейм про то какая студия гавно мне просто смешно. Кстати, настроил под себя более-менее аскетично: Согласно принятому у нас стилю кодирования нэймспейсы мы должны писать полностью и return только в конце процедуры как в седьмом обероне. Правда на 100% соблюдать кодингстайл пока удаётся только мне, но другие тоже как бы стремятся...