Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Ubivetz, Вы писали:
ZS>>>В Assемблер вам дорога!! Быстрее не придумаешь. U>>Неправда! Машинный код чуть быстрее
L>Это еще почему?
Потому что машинный видимо
Хотя конечто если взять например MASM версии хотя бы 5 и от души попользоваться всякими нехарактерными для нормального ассмеблера наворотами тогда то, что скомпилится, может оказаться не совсем тем, что хотелось
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Ты просто дурак! (не как оскорбление, а как оценка твоего интелекта на основе содержания твоего поста)
А когда осознаешь что ты дурак, будет очень поздно!
Я писал это на RSDN сто раз, однако для некоторых придется повторить:
1) Delphi — это инструмент быстрой разработки приложений.
Задача: написать приложение, автоматизирующее определенный бизнес процесс предприятия
Реализация:
а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 чел = $6400
б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в делфи уже на базе VCL сужествует огромная куча функциональности привязки к данным, формирования отчетов и т.д.) с окладом $800 (потому, что квалификации программистов для данной задачи достаточно, чтобы знать только VCL + на базовом уровне SQL). Бюджет: $400.
Результат:
В обоих случаях одно и тоже приложение. Теже самые поля ввода, те же самые формы, те же самые отчеты на принтер и т.д.
В приложении на Delphi время отклика на действия пользователя, допустим, 1,3 сек (из-за того, что все написано на громозтком VCL).
В приложении на C++ вреся отклика на действия пользователя, допустим, 0,8 сек (из-за того, что писали более грамотные программеры, на более низком уровне).
При составлении требований к разработки того или иного ПО отдельными пунктами указываются требования к производительности. И, допустим, если в реквайментах закащик указал — отклик не более 2 секунд, то значит оба варианта решают задачу.
Фактические различия:
Никаких, девка на рецепшене особой разницы не заметит в скорости обоих приложений.
Итог:
Нафига переплачивать больше? У IT-подразделения лишние $6000 баксов?
Задумайся над этим. И пойми — кроме того, что знать C++-реализацию алгоритма сортировки методом пузырька, надо еще быть немного экономистом. Иначе тебе ничего выше рядового программиста не светит в сфере IT.
P.S. Я каким либо образом унизил хотя бы одну из технологий? Я просто привел факты — пищу для размышлений.
P.P.S. C++ хорош, и Delphi хорош и все остальные технологии хороши. — просто надо знать где уместнее применять ту или иную технологию (естественно, для разработки приложения высокоточного вычисления магнитных полей изотопов расчепления атомов метана в абсолютно низких температурах, Delphi не совсем пойдет — там VCL особо не понадобится, а программа на трехэтажной математике банально будет работать в десятки раз медленнее).
P.P.P.S .NET Framework является некоторым заменителем концепций Delphi в быстрой и дешевой разработки приложений.
Здравствуйте, _wah, Вы писали:
_> Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве? _>или это очередное мнение очередного фаната делфи?
Я думаю, никто не спорит, что на NET писать быстрее. Сегодня NET пришел и вытяснил Delphi, но изначально эта ниша принадлежала именно ей. Когда небыло NET-а, то единственными альтернативани C++су были Delphi и VB — они и использовались, как инструменты быстрой разработки. Чего придераться к словам? (а? фанат .NET)
Здравствуйте, fessa, Вы писали:
F>Здравствуйте, cod3r_200, Вы писали:
_>> Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
F>Total Commander, если не ошибаюсь, на ней написан. Такую прогу я бы купил.
В том то и дело, что зависит все не от инструмента — а от того, от куда руки растут.
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана.
Я рад, что интернет доступен даже в детских садах! Моя родина всё же стремится не отставать от загнивающего запада, и это хорошо, это прекрасно!
Читай, деточка, интернет, развивайся, учись. Ты же блин наша смена! Только вот пиши поменьше, читай побольше, а то тебя оскорблять матерными словами будут, а тебе ещё рано их учить, надо годика четыре погодить исчо.
Здравствуйте, ShibaON, Вы писали:
SON> а время полной компиляции (если удалить все .dcu), обычно, не превышает и половины минуты, а так — секунды четыре.
Гы... Большой проект — это четыре часа компиляции Фортрана с вырубленной на хрен оптимизацией. С оптимизацией никто и не пытался компилять, ибо на фиг не надо.
Whistler wrote: > а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + > WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые > C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 > чел = $6400 > б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в > делфи уже на базе VCL сужествует огромная куча функциональности привязки > к данным, формирования отчетов и т.д.) с окладом $800 (потому, что > квалификации программистов для данной задачи достаточно, чтобы знать > только VCL + на базовом уровне SQL). Бюджет: $400.
Развиваем идею. Приложение понравилось, в него решили добавить новые
функции. Но в дельфяном приложении все построено на прямом биндинге
полей к результатам запроса (а как же — надо чтобы все было быстро
разработано), а в MFCшном приложении сделана объектная модель и выделен
слой работы с БД.
Поэтому MFCшники очень быстро прикручивают новую фичу, а дельфинисты
каждый раз перекурочивают половину форм. Причем получают в итоге
глючащее приложение из-за того, что постоянно забывают поправить
какой-то запрос.
Я лично такую ситуацию наблюдал не один раз. С помощью Дельфи/VB можно
очень быстро сделать начальное приложение, но вот потом поддерживать его
очень сложно.
Естественно, можно сразу писать на Дельфи красиво и нормально. Вот
только все магические улучшения производительности программиста куда-то
пропадут.
Здравствуйте, mishin, Вы писали:
M>Среды разработки Delphi и C++ Builder, насколько известно автору, не "доверяют" стандартным функциям управления кучей и реализовали свои.
Вообще-то этот алгоритм выделения памяти появился ещё когда разработчики дельфей под стол пешком ходили. Так что, пожалуйста, не надо вменять им это в заслугу.
Здравствуйте, Whistler, Вы писали:
W>Здравствуйте, _wah, Вы писали:
_>> Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве? _>>или это очередное мнение очередного фаната делфи?
W>Я думаю, никто не спорит, что на NET писать быстрее. Сегодня NET пришел и вытяснил Delphi, но изначально эта ниша принадлежала именно ей. Когда небыло NET-а, то единственными альтернативани C++су были Delphi и VB — они и использовались, как инструменты быстрой разработки. Чего придераться к словам? (а? фанат .NET)
не выспался?
шеф наорал?
в транспорте с кем-то поругался?
в предыдушем топике автора дураком обозвал,
меня тут в "фанаты" причислил..
IT — эта сфера в которой я зарабатываю себе на жизнь. И фанатизм тут не уместен. Для каждой конкретной задачи нужно подыскать конкретный инструмент (т.е. технологию) без излишнего фанатизма.
Cyberax тебе хорошо написал в сообщение от 22.08.06 00:52 Именно по этим причинам, даже тогда делфи не был ни конкурентом ни альтернативой чему либо.
п.с. мне есть с чем сравнить. Писал и на билдере, писал и на делфях, на vc++, теперь на дотнете. И кстати. переход в своё время моей фирмы с борландовских продуктов на vc++ был как раз обусловлен теми причинами, что описал Cyberax
Здравствуйте, Pyromancer, Вы писали:
P>Потому что машинный видимо
Хорошая шутка
P>Хотя конечто если взять например MASM версии хотя бы 5 и от души попользоваться всякими нехарактерными для нормального ассмеблера наворотами тогда то, что скомпилится, может оказаться не совсем тем, что хотелось
Главное при оптимизации кода — не изменить результат его работы
Здравствуйте, Cyberax, Вы писали:
C>Whistler wrote: >> а) Visual C++ — 2 месяца работы двух программистов, лабающих на MFC + >> WinAPI и требующих зарплаты $1.6к (только потому, что они нефиговые >> C++-программеры, а не какие-то делфисты тупые). Бюджет: 1.6 * 2 мес * 2 >> чел = $6400 >> б) Delphi 7 — 2 недели одного Delphi-программиста (просто потому, что в >> делфи уже на базе VCL сужествует огромная куча функциональности привязки >> к данным, формирования отчетов и т.д.) с окладом $800 (потому, что >> квалификации программистов для данной задачи достаточно, чтобы знать >> только VCL + на базовом уровне SQL). Бюджет: $400. C>Развиваем идею. Приложение понравилось, в него решили добавить новые C>функции. Но в дельфяном приложении все построено на прямом биндинге C>полей к результатам запроса (а как же — надо чтобы все было быстро C>разработано), а в MFCшном приложении сделана объектная модель и выделен C>слой работы с БД.
C>Поэтому MFCшники очень быстро прикручивают новую фичу, а дельфинисты C>каждый раз перекурочивают половину форм. Причем получают в итоге C>глючащее приложение из-за того, что постоянно забывают поправить C>какой-то запрос.
C>Я лично такую ситуацию наблюдал не один раз. С помощью Дельфи/VB можно C>очень быстро сделать начальное приложение, но вот потом поддерживать его C>очень сложно.
C>Естественно, можно сразу писать на Дельфи красиво и нормально. Вот C>только все магические улучшения производительности программиста куда-то C>пропадут.
Если перелопачивать половину форм — это не фича а коренная переделка при изначально неверном проектировании. И здесь в MFC будет такая же ж.... Ибо когда неправильно спроектирована объектная модель проблем не меньше это точно. Если изначально грамотно спроектировать приложение, то будь оно на C++ и ли на дельфи добавлять новый функционал будет легко и приятно.
p.s. Слой работы с БД не есть особенность MFC, при необходимости его можно прикрутить куда угодно.
alex_kostylev wrote: > C>Естественно, можно сразу писать на Дельфи красиво и нормально. Вот > C>только все магические улучшения производительности программиста куда-то > C>пропадут. > Если перелопачивать половину форм — это не фича а коренная переделка при > изначально неверном проектировании.
Неа, это реалии жизни. Поменялась структура БД — и начинается колбашение
в формах.
А структура БД при RAD-разработке редко с первого раза бывает нормальной.
> И здесь в MFC будет такая же ж.... > Ибо когда неправильно спроектирована объектная модель проблем не меньше > это точно. Если изначально грамотно спроектировать приложение, то будь > оно на C++ и ли на дельфи добавлять новый функционал будет легко и приятно.
Вот только уже не будет таких суперкрутых преимуществ в скорости разработки.
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Здравствуйте, Ubivetz, Вы писали:
U>Здравствуйте, ZevS, Вы писали:
ZS>>В Assемблер вам дорога!! Быстрее не придумаешь. U>Неправда! Машинный код чуть быстрее
Это ваша неправда — быстрее фортрана ничего не предумано, потому что "он выполняет программы минуя процессор" (c) народ. 1997 год.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, siberia2, Вы писали:
_>>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов.
S>Вы полагаете, что прога на буилдере от борланд будет работать лучше?
Создание прог на "буилдере от борланда" ничем не отличается от создания прог в других средах.
В чем-то лучше, в чем-то хуже.
Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. В итоге получаю дополнительную уверенность что все нормально
Насчет багов BCB ... а где их сейчас нет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Коваленко Дмитрий wrote: > Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8.
А вы, случайно, не используете IBM XT для контроля качества генерации
кода для Core 2 Duo?
Здравствуйте, Cyberax, Вы писали:
C>Коваленко Дмитрий wrote: >> Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. C>А вы, случайно, не используете IBM XT для контроля качества генерации C>кода для Core 2 Duo?
Нет, для него я использую двухпроцессорный антиквариат на базе PII-450
Я понимаю ваши издевательства над BCB5. Я сам люблю над ним измываться.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, Cyberax, Вы писали:
C>>Коваленко Дмитрий wrote: >>> Я, к примеру, использую компилятор от BCB5 для контроля компилятора VC8. C>>А вы, случайно, не используете IBM XT для контроля качества генерации C>>кода для Core 2 Duo?
КД>Нет, для него я использую двухпроцессорный антиквариат на базе PII-450
КД>Я понимаю ваши издевательства над BCB5. Я сам люблю над ним измываться.
Не надо издеваться над средами разработки. Если уж так приспичило, то уж над программистами что не умеют в них работать
Именно по этим причинам, даже тогда делфи не был ни конкурентом ни альтернативой чему либо.
