Delphi - "рулез форева"!

← →
Делфиец (2010-02-14 22:43) [40]

Большим недостатком .NET - жрет память гадина постоянно.
Когда начинали проект, закупили по тем временам компьютера (2.4 гц. целероны 256мб. оперативки) средней мощности, но года установили армы написанные на С# + Фреймворк 2.0 MS SQL Expres на каждый, то поняли что памяти мало только фреймворк при загрузке 40-70мб отъедает памяти, тогда пришлось на всех компьютерах увеличить память до 512мб. Через некоторое время опять возникли проблемы (через 1.5 года работы АРМов) Базы разбухли и достигли предела, который ограничивался 4гб. согласно лицензии от MS на Expres версию. Ситуация была трудной - никто не знал что произойдет, когда базы достигнут более 4гб. А производство остановить нельзя, т.е. невозможно (великий глюк наступит) приходилось их чистить постоянно, удаляли лишние события и служебные записи и логи во вред безопасности. Теперь ситуация более менее, но уже снова приходится увеличивать память на компьютерах до 1гб., но уже возникла другая ситуация компьютеры уже устарели и память DDR1 днем с огнем не сыскать, а там где она есть в той фирме конторе покупать нельзя, а значит по сути ее нет.
Ну асли бы использовали Субд с использованием NET 3.5 версии, вообще бы "слили воду бы" .

← →
@!!ex © (2010-02-14 22:49) [41]

> [40] Делфиец (14.02.10 22:43)

ИМХО .NET - бред безумца... Редкостная гадость.
ИМХО ИМХО ИМХО ИМХО ИМХО

← →
boa_kaa © (2010-02-14 22:49) [42]

> Делфиец (14.02.10 22:43) [40]

а посмотреть системные требования на MS SQL, конечно, никто не догадался...

← →
boa_kaa © (2010-02-14 22:52) [43]

> @!!ex © (14.02.10 22:49) [41]
> ИМХО .NET - бред безумца... Редкостная гадость.
> ИМХО ИМХО ИМХО ИМХО ИМХО

а чем? а чем? а чем? а чем? а чем?

← →
Вовчик (2010-02-14 22:57) [44]

2 @!!ex

Не устанавливаются компоненты в dclusr.dpk. То ли я чего не так делаю, то ли в скачанном дистрибутиве от 21 июня 2007 года этот "баг" пофиксили. Если второе, то как бы поиметь более старую версию дистрибутива Turbo Delphi, которая все еще поддерживает установку пользовательских компонентов?

← →
Делфиец (2010-02-14 23:01) [45]

> Демо © (14.02.10 22:42) [39]

Что ля - ля то..
Что то еще не у кого не видал на производстве. только в нашей конторе свыше 2000 компьютеров и ни как не видел, что хоть кто-нибудь в дирекции информационных технологий заморачивался по 64 разрядным системам, кроме как на серверах. Это дома для своих целей хоть, что устанавливайте, единичные случаи не в счет.
1. лицензии на 64 разрядные ОС дороже, а значит и покупать "большими пачками" ни кто не будет.
2. возможно есть некие проблемы в совместимостью с уже написанными и работающими 32бит. АРМ`ами 1С, Ораклом и уже всем поглощающим САП`ом, мы не тестировали, да и вы не тестировали, их переписывать никто не будет под 64бит а значит так и останутся 32бит. Тогда вопрос, а зачем нам в таком случае 64битные ОС, если на них все равно будет 32 битное ПО и АРМы крутиться будут?

← →
Делфиец (2010-02-14 23:14) [46]

> boa_kaa © (14.02.10 22:49) [42]
> > Делфиец (14.02.10 22:43) [40]а посмотреть системные
> требования на MS SQL, конечно, никто не догадался...

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

← →
Дмитрий Белькевич (2010-02-14 23:42) [47]

Замена эврикалога для QT есть? Кстати, для нативных плюсов тоже интересны аналоги.

← →
Игорь Шевченко © (2010-02-14 23:48) [48]

Делфиец (14.02.10 23:01) [45]

> Тогда вопрос, а зачем нам в таком случае 64битные ОС, если
> на них все равно будет 32 битное ПО и АРМы крутиться будут?
>

Даже для 32-х битных приложений под 64-битными системами физической памяти памяти больше видно.

В 64-х битных системах проблем нет ни с ораклами, ни с виндами, ни с .Net-ом. Проверено электроникой.

← →
Плохиш © (2010-02-15 00:01) [49]

> Делфиец (14.02.10 23:14) [46]

А мелкий софт по-привычке виноват?

← →
Германн © (2010-02-15 02:24) [50]

Справился с этой "поделкой/(подделкой под нормальный продукт)".
Оказывается он очень критичен к файловой структуре проекта. Вот уж блин не ожидал такого! В него можно добавить любой "модуль в его понимании" из любого места в файловой системе компа и он не ругается. Но последствия - не предсказуемы. Либо проект будет не читаем при следующем открытии, либо он не сможет быть откомпилирован, либо...

← →
Германн © (2010-02-15 02:28) [51]

При этом нашел ещё и дополнительную претензию к разработчику/MS. Ту самую .Net-библиотеку приходится лОжить рядом с исполняемым файлом. Других вариантов не нашел.

← →
Делфией (2010-02-15 15:00) [52]

> Игорь Шевченко © (14.02.10 23:48) [48]
</I
> Даже для 32-х битных приложений под 64-битными системами
> физической памяти памяти больше видно.

>

А для клиентского ПО запредельной памяти и не нужно, а если то про что я выше писал, что не хватает оперативки для нашей АСУДС, ну так все-таки некоторым программистам бы руки кувалдой выровнять нужно. До 2008 г. старая система еще на СМ1420 работала на "Диамс" с диском на сервере в 16мб. и вся база туда свободно умещалась за несколько лет, а сейчас на новой системе после работы пару годков уже незнаемо как базу разместить так как на сервере никаких дисков не хватает.
Отсюда мораль, что огромное и расточительное потребление памяти вероятно не обосновано.

← →
Делфиец (2010-02-15 15:05) [53]

> Плохиш © (15.02.10 00:01) [49]
> > Делфиец (14.02.10 23:14) [46]А мелкий софт по-привычке
> виноват?

А то кто же? Мне есть с чем сравнивать, я еще на СМ-ках работал.

← →
asail © (2010-02-15 15:49) [54]

> Делфией (15.02.10 15:00) [52]

Это все так, конечно... Но зачастую скорость разработки перевешивает требования к системным ресурсам.
Например, можно написать за год продукт, который требует 1Гб оперативки для работы. А мона, чтоб 256Мб требовал, но за 2 года... А мона и чтоб на 16Мб пахал, но 10 лет убить на разработку... На ассемблере... И биться до победного за каждый байт... Вопрос - а нафига?
ИМХО.

← →
Игорь Шевченко © (2010-02-15 16:25) [55]

> До 2008 г. старая система еще на СМ1420 работала на "Диамс"
> с диском на сервере в 16мб. и вся база туда свободно умещалась
> за несколько лет, а сейчас на новой системе после работы
> пару годков уже незнаемо как базу разместить так как на
> сервере никаких дисков не хватает.

Это натурально MS виноват. Только одно непонятно - кто вам мешал и после 2008 года оставаться на CM1420 с диском в 16Мб ?

← →
Дмитрий Белькевич (2010-02-15 16:27) [56]

>Это все так, конечно... Но зачастую скорость разработки перевешивает требования к системным ресурсам.

В реальной жизни, массовые продукты (ну разве что кроме игр) не стоит разрабатывать под топовое железо.

← →
Дмитрий Белькевич (2010-02-15 16:30) [57]

> Например, можно написать за год продукт, который требует
> 1Гб оперативки для работы. А мона, чтоб 256Мб требовал,
> но за 2 года...

Мона сделать нормальную архитектуру и сделать 256 мб за год. Ну а если левой ногой делать - то и 8 гиг будет мало.

← →
Кто б сомневался © (2010-02-15 16:33) [58]

> @!!ex © (14.02.10 20:00) [21]
>
> > [19] miek (14.02.10 19:54)
>
> Проблема дельфи не столько в том, что она дорогая... а в
> том что она убогая.
> IDE просто отличная, но сама концепция устарела и не развивается.
>
> Компилятор только под Win и только 32(это во вреемена, когда
> уже практически нельзя купить новый 32 битный комп).
> VCL нормально работает только в однопоточной среде(это во
> времена, когда на конвеер уже поставлены 8 ядерные процессора).
>
>
> Это все и заставило лично меня заняться поиском альтернатив.
> :(

Т.е. по твоему она убогая т.к. нет x64 и однопоточная VCL (что в реальности не существенно - т.к. распаралеливаются свои задачи без проблем).
Вот эти 2 проблемы, т.к. другие настолько не критичны.
И поэтому ты начал искать альтернативу?
Что там за программы то такие? И всем твоим программам реально необходим x64 (именно всей программе, а не какому то модулю из пакета программ?)?

← →
Дмитрий Белькевич (2010-02-15 16:36) [59]

Недавно. Перелезли на новые DelphiX. В TDIB добавили статический буфер: FLUTDist: array[0..255, 0..255]. Кажется - мелочь. Результат - на загруженных в TDIB 2000-ах картинок потерялся гиг. Переписал на динамику: array of array of Integer; гиг нашёлся. Почему бы сразу не сделать...

← →
Кто б сомневался © (2010-02-15 16:38) [60]

Я сколько игрушек играю, и очень редко попадаются игрушки с exe x64. А ведь прежде всего подобным программам реально нужно x64 для доступа к больши массивам памяти.
Реально редко, - т.к. разработчикам тестировать надо будет в 2 варианта - а это в 1,5 раза больше работы.

← →
@!!ex © (2010-02-15 16:50) [61]

> [58] Кто б сомневался © (15.02.10 16:33)

Для меня три критерия сыграли роль:
1) Кроссплатформенность. Так уж сложилось что для меня очень важный критерий. Windows, к счастью, это еще не все компы.
2) Это то, что один из проектов над которым сейчас работаем планируется продавать вместе с сорсами. А сорсы на дельфи сейчас мало кому нужны.
3) Сложно найти адекватных дельфи 3Д программистов. Я вообще на этот критерий плевал.. но сейчас работаем с программистом на С++. И варианты: либо я перехожу на С++, либо он переходит на дельфи... причин переходить на дельфи нет ниодной... хотя я, естественно, сначала хотел все делать на дельфи.. но потом включил мозг.

← →
Кто б сомневался © (2010-02-15 16:56) [62]

Ну вот, это совершенно другие критерии. А в плане гуишных прог под win, delphi обыгрывает по скорости и удобству разработки.

> Сложно найти адекватных дельфи 3Д программистов.

А разве в 3d в delphi и С ++ разные технологии используются? Я думал одинаковые, втч и библиотеки.

← →
Дмитрий Белькевич (2010-02-15 16:57) [63]

Лично мне не хватает памяти. Я бы не отказался от x64 именно из-за объёмов доступной памяти. Данных бывает реально много и ужать уже нельзя - все разумные меры уже предприняты. Одно время данные даже сжимал "на лету" в памяти - потом отказался. Но куда-то перелазить - нет смысла. Все наработки на Delphi. Многие куски уже начали повторно использоваться. Хорошо изучена. Много стороннего и достаточно дорогого куплено. Жду версию под x64.

Вообще - потенциально можно было бы менеджер памяти переписать под использование AWE, но не думаю, что этим стоит заниматься - будем ждать x64.

Однопоточная VCL особенно не напрягает.

← →
Кто б сомневался © (2010-02-15 17:00) [64]

> И варианты: либо я перехожу на С++, либо он переходит на
> дельфи... причин переходить на дельфи нет ниодной..

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

> Жду версию под x64.

В чем проблема, переписывается какой то модуль под паскалевский x64 компилятор и все.

← →
@!!ex © (2010-02-15 17:01) [65]

> [62] Кто б сомневался © (15.02.10 16:56)
> А разве в 3d в delphi и С ++ разные технологии используются?
> Я думал одинаковые, втч и библиотеки.

Нет. Проблема скорее в том, что редко кто занимается графикой на дельфи.
То есть либо специалист в дельфи, либо в графике, редко и то и другое.
Я знаю 4 человека которые профессионально пишут графику на дельфи и все они уже заняты...
а на С++ полно народу.

← →
@!!ex © (2010-02-15 17:02) [66]

> [64] Кто б сомневался © (15.02.10 17:00)
> Так сложилось исторически, что игры делают на С++. Под этот
> язык масса шаблонов и модулей уже проработанных.

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

← →
Игорь Шевченко © (2010-02-15 17:11) [67]

> Сложно найти адекватных дельфи 3Д программистов

Адекватных программистов вообще сложно найти.

← →
Кто б сомневался © (2010-02-15 17:18) [68]

> усугубляется тем, что я на С++ медленней пишу из-за отсутствия
> опыта.

А еще также неудобство и нелюбовь, когда после Delphi с его продуманным прозрачным синтаксисом, C++ кажется каким то монстром, все время возникает вопрос, чем руководствовался человек, который придумывал этот язык, когда придумывал такие сложности и символы в синтаксисе на ровном месте и зачем он это делал. Почему нельзя было просто написать - or, and, итп.
Кем надо быть, чтобы усложнить до && и || где тут логика? Ну что мешало ему написать and вместо &&? Такое чувство что спецом хотели усложнить жизнь.
А вот это >>? Ну что мешало ему написать shr? Ведь скорость восприятия человеком сокращения shr выше.

> [18] @!!ex © (14.02.10 19:33)

> Там же прямой доступ к ОС функциям. Типа:
> painter.paintEngine()->getDC() - и вот уже у нас виндовый
> HDC обычный.

можно ли вызывать напрямую API хотя бы как это сделано, к примеру, в .NET? даже если можно, то теряется основной смысл QT, т.к. теряется кроссплатформенность. отсюда вывод, для приложений тесно взаимодействующих с ОС и сильно зависящих от окружения нет особого смысла и заморачиваться с лишними прослойками.

> Компилятор только под Win и только 32

да это существенный недостаток. посмотрим, может летом выпустят обещанный x64.

> VCL нормально работает только в однопоточной среде(это во
> времена, когда на конвеер уже поставлены 8 ядерные процессора)
> .

зачем для GUI несколько потоков?

> [60] Кто б сомневался © (15.02.10 16:38)

> Я сколько игрушек играю, и очень редко попадаются игрушки
> с exe x64. А ведь прежде всего подобным программам реально
> нужно x64 для доступа к больши массивам памяти.
> Реально редко, - т.к. разработчикам тестировать надо будет
> в 2 варианта - а это в 1,5 раза больше работы.

через год-два все будет строго наоборот.

! - почему бы просто не написать not? Откуда к нему вообще пришла эта ассоциация, что восклицательный знак, должен стать not?

Ветку не читал, но осуждаю.

> Ну что мешало ему написать and вместо &&?

Потому что короче. Наследие си. Когда памяти были считанные килобайты было важно.

← →
Дмитрий Белькевич (2010-02-15 17:34) [73]

Холивар детектид :)

>[61]

Удобнее писать на плюсах - пиши. Для наших условий Делфи подходит идеально - его и используем.

1. Сырцы закрытые и продавать не планируется.
2. Кроссплатформенность в текущих проектах не нужна. Хотя под кпкшник было бы интересно некоторые вещи бесплатно зарелизить. Жду Delphi для телефонов.
3. Есть несколько адекватных программистов под задачи + я сам. Хватает.

> Дмитрий Белькевич (15.02.10 17:34) [73]

аналогично

← →
Дмитрий Белькевич (2010-02-15 17:36) [75]

> Когда памяти были считанные килобайты было важно.

Фортран был раньше с и сильно длиннее. И как-то хватало.

> Потому что короче. Наследие си. Когда памяти были считанные
> килобайты было важно.

Непонятно тогда почему сетевые языки, подхватили эту глупую традицию.

← →
jack128_ (2010-02-15 17:42) [77]

> Потому что короче. Наследие си. Когда памяти были считанные
> килобайты было важно.

хм. а в скомпилированном коде выражение not x занимает меньше, чем !x ?? или имеюттся в виду килобайты для хранения сорцов??

> Кем надо быть, чтобы усложнить до && и || где тут логика?
>

& - это и означает "and". см например названия компаний (Procter & Gamble и тому подобное)

← →
Дмитрий Белькевич (2010-02-15 17:45) [78]

Продолжим холивар :)

Чем не нравится дотнет. Собрал в себе два минуса - ограниченную кроссплатформенность. Не знаю, можно ли вообще назвать кросплатформенностью официальную работу только под операционками от MS. И более медленную работу. Кто бы что не говорил, и какие синтетические тесты не приводил - но дотнет работает медленнее.

Посему неясно, зачем он вообще может быть полезен. Под wintel есть нативные среды - Делфи/Билдер/Плюсы. Под кроссплатформенность есть жава.

Единственное - если программа должна работать одновременно и на WM и на обычной W. Но я слабо себе представляю такую программу (сложнее Hello World), которая будет из одних сырцов нормально работать и там и там без учёта в этих сырцах, где сейчас работаем.

Так что моё мнение, что дотнет в текущем состоянии - тупиковая ветвь.

& - образовалась от совмещения букв "e" и "t". От латинского "et" - "и"

← →
Дмитрий Белькевич (2010-02-15 17:48) [80]

> & - это и означает "and". см например названия компаний
> (Procter & Gamble и тому подобное)

Почему бы уже тогда не & а &&?

> или имеюттся в виду килобайты для хранения сорцов??

Ну - я думаю это имелось в виду.

Delphi - "рулез форева"! Найти похожие ветки