Ответ на »сообщение 40« (panda)
___________________________
Теперь мы будем использовать не ворованную BDS, а бесплатный Turbo Delphi/C++/C#. Только и всего. Аминь. :-)

Ответ на »сообщение 40« (panda)
___________________________

>Т.е. Visual C - плохой инструмент для ЛЮБЫХ задач?

Никак нет. Но если человека угнетает длительность компиляции в Це, то ему есть смысл подумать о Дельфи.

>И ВСЕМ лучше использовать ворованую BDS, чем бесплатную версию Visual Studio.

Большинству. Кроме самых рьянных поборников за инт. собственность или в условиях слишком жесткого контроля.

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

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

Ответ на »сообщение 36« (TEvg)
___________________________

С некоторыми из этих шагов я согласен, с другими нет в частности с необходимостью сверхмощного оборудования. Мол больше 15 секунд работает компилятор - раздражает.
А дольше скольки раздражает? 30 секунд, 50, 5 минут?

Чтоб не  раздражало надо правильные инструменты использовать, а не визуал Це.
Т.е. Visual C - плохой инструмент для ЛЮБЫХ задач? И ВСЕМ лучше использовать ворованую BDS, чем бесплатную версию Visual Studio.

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

Мое начальство расщедрилось на новую машину 3,2 ГГц, 1 Гб ОЗУ и прочее. Стало не так удобно вылавливать узкие места. Их просто не замечаешь. Стало быть надо на своей машине написать, а потом на слабую машину перейти и там глюки ловить. Неудобно! Если сразу на слабой пишешь, то и тормоза преодолеваешь по мере появления, а не потом пытаешься вспомнить, чем руководствовался при написании того или иного кода.
Ловить тормоза по субъективным ощущениям разработчика, а не по профайлингу - по меньшей мере, весьма странное занятие.

Что тут скорость компиляции сравнивать! У языков С-семейства есть чисто "генетические" проблемы, которые приводят к "торможению" кода.
Чтобы не тратить время на словотворчество даю цитату в сокращенном виде:
"Типичная Си-строка представляет собой цепочку однобайтовых символов, завершаемую специальным символом конца строки - нулевым байтом. Это крайне неоптимальная структура данных, особенно для современных 32-разрядных процессоров! ...
По тем же самым причинам невозможно реализовать эффективное копирование и объединение Си-строк. Действительно, как прикажете копировать строку не зная какой она длины?
Всех этих недостатков лишены Pascal-строки, явно хранящие свою длину в специальном поле, расположенном в самом начале строки. Для вычисления длины Pascal-строки достаточно всего одного обращения к памяти (грубо говоря, длина Pascal-строк может быть вычислена мгновенно)." - конец цитаты

Где-то я даже анекдот читал на эту тему - если найду, то напишу. Суть анекдота в том, что организация представления символьных строк в языке С и во всех, кто от него произошел сделана через одно место.

ТО TEvg
Я недавно делал пару проектов - один на Дельфях, второй на Визуал С#.
Оба - клиентские программы, взаимодействующие с БД, примерно равноценные по сложности и объему.
Я не мерял время компиляции секундомером, но на глаз разницы заметно не было.

Ответ на »сообщение 36« (TEvg)
___________________________

На машине P4 - 2.8ГГц, ОЗУ 1.5Гб компиляция проекта объемом около 370 тыс. строк - 12 сек,
То же самое на машине P4 - 1.4 ГГц, ОЗУ 760 Мб - 13 сек. Разброс в пределах ошибок запуска секундомера, так что на слабой машине может было и бысрей! Но иногда бывает, что и на быстрой машине компилится около 30 секунд, не знаю - почему, не  разбирался. Только что померил ради интереса. Так что Delphi особо не чувствительна к мощности машины. Этого не скажешь про работу самой программы - на более мощной машине она работает соответственно быстрей. А пускать за день приходится сотни раз, так что у программиста должна быть машина мощная. А проблемы, связанные с быстродействием, можно и на слабой машине найти, тестеры их находят почти сразу же, потому что у них работают машины и самых слабых заказчиков. Если нет тестировщиков - то все может быть иначе.

>Почитали бы Вы умных людей, что ли, на эту тему. Например, Тест Джоэла: 12 шагов к лучшему коду

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

Мое начальство расщедрилось на новую машину 3,2 ГГц, 1 Гб ОЗУ и прочее. Стало не так удобно вылавливать узкие места. Их просто не замечаешь. Стало быть надо на своей машине написать, а потом на слабую машину перейти и там глюки ловить. Неудобно! Если сразу на слабой пишешь, то и тормоза преодолеваешь по мере появления, а не потом пытаешься вспомнить, чем руководствовался при написании того или иного кода.

Ответ на »сообщение 33« (TEvg)
___________________________

Программировать надо на машине чуть ниже среднего.
Почитали бы Вы умных людей, что ли, на эту тему. Например, Тест Джоэла: 12 шагов к лучшему коду
По своему опыту могу зказать, что полностью согласен с Джоелом. При разработке у программиста должна быть самая мощная техника. А вот тестирование быстродействия надо проводить на более слабых машинах.

>Кто-нибудь может сказать, чем это пахнет?

Я не разделяю панических настроений по поводу возможного прекращение работы над Дельфи. Своей вершины Дельфи достигла в 3-й версии, а в 5-й к ней прикрутили все что нужно для удобной работы. После чего какие-либо улучшения здесь стали невозможны. Борланду надо было не исполнять танцы с бубнами, а оставить Дельфи жить самой по себе, также как BP. А самой фирме реализовывать с нуля какую-либо новую идею. Смерть дельфи не грозит до тех пор пока существует винда и писюк. Отказ от винды произойдет еще очень не скоро. Прижились же DOS с паскалем в встраиваемых промышленных системах. Сетевые карточки с дровами под DOS выходят. Хотя казалось бы что время DOS вышло. Единственное что огорчает - среди тупорылых манагеров усилится точка зрения, что дельфия - это немодно и неперспективно.

С автором полностью согласен. Именно Дельфия 5 Про + АСПак.
Конечно пользоваться лучше Дельфией Client/Server, которая легко приобретается за пару десятков руб. А диск с легальной Дельфи следует положить в сейф и бережно хранить.
Из СУБД - Interbase. В последнее время приходится использовать Oracle, чисто технически очень приятная вещь, неприятности начинаются в областях экономической и юридической.

>Ну с железом все более или менее понятно - чем круче компьютер, тем лучше.

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

______________________________________
>Уважаемый, Алексей, искренне сочуствую Вашему горю - Вам пришла в голову мысль о разработке серьезного ПО с помощью delphi - это пагубная  мысль! Мой Вам совет забудьте слово pascal, и, тем более, слово delphi - в терминологии разработки АСУ таких слов нет. И приобретите себе такой программный продукт, как MS Visual c++ v6.0, желательно Enterprise edition или Prof. - она попроще и подешевле.
_______________________________________

Никаких преимуществ Визуал Це перед Дельфи не имеет в т.ч. в области АСУ. Это дело вкуса. Неоднократно встречался с успешным применением Паскаля/Дельфи в АСУ: станки, осциллографы, тепловая автоматика, местрополитен, авиация и т.д. Разумеется все это можно реализовать и на Це. И конечно во всех этих областях встречаются реализации и на Це. Неоднократно видел и применение Це быдлера в АСУ, который базируется на той же VCL. К примеру учет энергии в энергосистемах Украины и Казахстана. DOS  с турбо паскалем часто применяется в промышленных РС-совместимых модулях. Маленькие такие коробочки с выводами портов (RS-485, Ethernet), внутри которых х86 процессор, флэшь-диск и операционная система DOS. И лучше турбопаскаля тут ничего не придумаешь.

>>Но что приобрести в качестве средства разработки?
>Зависит от задачи.

Не совсем согласен. На каждую задачу покупать инструмент - и разоришься и не будешь толком владеть ни одним из них.

>Delphi? Какую версию Delphi посоветуете исходя из соотношения цена/качество?

Пятую.

>Если задача, не писать программЫ, а обслуживать одно конкретное предприятие (нужно быть в этом уверенным, чтобы не выбрать не тот путь), то советую использовать Access.

Я недолюбливаю Аксесс. И считаю что в задачах где хорошо применять Аксесс лучше применять вообще Ексель. А потом сразу подниматься на следующую ступеньку - к Дельфи + какая-нибудь СУБД. Лучше Interbase. Еще очень приятное впечатление оставил Парадокс. По скорости и безглючности.