Как эффективнее перелезть на VS.NET?

← →
Layner © (2006-07-04 11:58) [40]

ну блин, дожили, на сайте по Delphi народ сваливает на студиу. Но видимо по привычке ещё тут обитает :) ПОнятно, конечно, C++ всегда был более предпочтительным для винды, но по мне D7 нравится, работы хватает вроде, перехходить тоже пока не собираюсь. Но посматриваю конечно, чего греха таить, но только для конкретных целей, например задача под разбор XML, или элементы ActiveX пишу.

← →
DrPass © (2006-07-04 12:33) [41]

> C++ всегда был более предпочтительным для винды

Не о С++ речь - он, будучи за уши притянут на .NET-платформу, там же и отомрет :)

← →
Nic © (2006-07-04 13:59) [42]

> Курдль © (04.07.06 10:18) [39]

Если удастся открыть студию и будет "работаем" и если причины переходить будут, то проблем с освоением не возникнет. Вместо begin будет {, вместо uses будет using и наймспейсы. Язык на самом деле несложный.

← →
Курдль © (2006-07-04 14:05) [43]

> Язык на самом деле несложный.

А я и не говорил, что сложный. Я вообще против "языковой зависимости". И не только я, а все "мировое прогрессивное программерское сообщество" :)
Думаю, тот, кто сможет разработать среду для проектирования на уровне паттернов, определит ближайшее будущее программирования.

← →
Alkid © (2006-07-04 14:13) [44]

Что значит "на уровне паттернов"? Типа нарисовал стопку UML-диаграмм и получай готовый продукт? Я к этому скептически отношусь в том смысле, что всё равно для задания какой-то бизнес-логики в программе необходимо в компутер ввести определённое количество информации. И мне кажется, что ввод этого дела в виде текста (aka исходного кода на языке программирования) удобнее, чем в виде диаграмм. Ну это моё имхо.
А вот за более тесную интеграцию средств моделирования и разработки - так я руками и ногами за. :)

← →
ZeroDivide © (2006-07-04 14:27) [45]

> Ведь самая главная проблема - это не изучение нового языка,
> это перенос существующего кода под новую платформу.

...Я-то думал, что основная проблема - это все усложняющиеся проекты, которые приходится делать "с нуля"...

Ты ошибался

а не старые изделия, которые надо поддерживать на плаву любыми силами.
Речь идет прежде всего о технологиях и наработках, а не о изделиях... если появился CLR, то это не значит, что все остальные технологии куда то пропали. Единственное что изменилось - код стал управляемым. Это тот же самый код, с той же самой функциональностью, только управляемый. Так что "с нуля" писать разумеется не приходится. И как заметил DrPass © (03.07.06 12:51) [22] "И не только у нас - в Microsoft, например, ситуация такая точно :-)"

← →
Курдль © (2006-07-04 14:45) [46]

> Что значит "на уровне паттернов"? Типа нарисовал стопку
> UML-диаграмм и получай готовый продукт?

В идеале - да! :) Кто бы мог представить 20 лет назад, что можно нечто запрограммировать, "набросав на форму компонентов"?!

Однако, в VS уже многие классы приближены к идеологии паттернов: "Адаптер", "Комманд", "Прокси".

> ZeroDivide © (04.07.06 14:27) [45]

Я не готов особо спорить с тем, что поддержка старых изделий важна. А старые наработки и технологии... Не знаю, как у Вас, но у нас в проектах 80% трудозатрат - на проработку концепции автоматизации предметной области. А процесс "архитектура-модель данных-кодирование-тестирование" проблем не вызывает. Технология - это шире. Это опыт ведения переговоров с должностными лицами, взаимодействие с ответственными исполнителями, работа аналитиков по исследованию автоматизируемого бизнеса, планирование и бюджетирование и мн.др, на первый взгляд не относящееся к IT...

← →
Alkid © (2006-07-04 15:11) [47]

> В идеале - да! :) Кто бы мог представить 20 лет назад,
> что можно нечто запрограммировать, "набросав на форму компонентов"?
>
> Однако, в VS уже многие классы приближены к идеологии паттернов:
> "Адаптер", "Комманд", "Прокси".

Ну, паттерны это конечно здорово, но это не панацея и зацикливаться на них не стоит. Даже сама банда четырёх не раз указывает на то, что это только частные решения отдельный задач и собрать всё приложение из них не всегда можно. Кроме того, излишнее увлечение паттернами - это уже общепризнанный антипаттерн :) Так что я оцениваю это дело не с точки зрения, насколько поддерживаются там именно паттерны, а вообще ОО-разработка, что есть несколько более широкое понятие.

← →
Курдль © (2006-07-04 15:21) [48]

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

Кстати, мне ближе паттерновый подход GRASP, чем GoF. Он более архитектурен или глобален, что ли... Там всего десяток паттернов, но они не являются догмой а лишь определяют критерии, по которым следует делить систему на функциональные модули.

← →
Alkid © (2006-07-04 15:38) [49]

Ну, GRASP и GoF - это совершенно разные вещи. То, о чём ты говорил выше, это скорее именн GoF с их структурными, поведенческими и прочими паттернами. GoF - это в больше степени набо готовых схем, а GRASP - это в больше степени философия. Если интеграция поддержки паттернов в стиле GoF достаточно очевидна, то как вносить поддержку GRASP - это надо ещё разобраться компетентым органам.

> Alkid © (04.07.06 15:38) [49]

Все правильно! Под гипотетическим вариантом "программирования паттернами" я имел в виду GoF. :)
А вот GRASP - это уже методология. И если грамотно подойти, вооружившись последней, да настрогать полезных (а не каких попало) паттернов из первой, - тогда можно значительно упростить процесс автоматизации. Вот это и будет отработанной технологией! Зная, как и какие шаблоны надо создавать для конкретной системы, можно легко отвязаться от реализации. Ведь, к примеру, не составит труда повторить "фабрику классов", созданную однажды на Java и под C++ и под Delphi.

В принципе такое можно было бы организовать следующим образом:
1. Мощный механизм шаблонов.
2. Обширная библиотека паттернов-шаблонов, рождённых из слияния в экстазе GoF и GRASP. Типа STL, но по паттернам.
3. Мощное средство моделирования\визуальной разработки, заточенное на создание проекта в виде модели с кастомизацией всяких там свойств и т.п.

В принципе идея красивая, но чует моё сердце тут эшелоны подводных камней, расложенных в самых неожиданных местах.

> В принципе идея красивая, но чует моё сердце тут эшелоны
> подводных камней, расложенных в самых неожиданных

Какие навскидку шаблоны можно представить себе графически?
Адаптер, контроллер, фабрику...
О! Вспомнил забавный инструмент, не виданный мною ранее и ни на что не похожий - среда разработки процесса интеграции данных "Informatica Power Center". Она позволяет графически спроектировать прохождение потоков данных от "источника" к "приемнику" через "трансформации".
Это я к тому, что идет процесс визуализации проектирования в разных областях IT!

> Язык на самом деле несложный.

Но всё же есть кое-какие нюансы, если верить блогу
http://blogs.msdn.com/ericlippert/

Как эффективнее перелезть на VS.NET? Найти похожие ветки