Сообщений в теме: 112

[Zulkar]

А скажите, что с Kylix ? Списан со счетов ? Ведь тоже альтернатива Delphi Кто-нибудь на нем делал чего-нибудь ?

Kylix изначально был мертворожденным.

[skiboo]

Совершенно верно. Все дело в программерах. На дельфи можно очень даже хорошие и большие программы делать.

Не, большие лучше не делать, там когда кода дофига на него страшно смотреть, 95 винду напоминает и эти долбаные begin end глаза мазолят. Хотя не спорю очень даже можно и большие проекты делать. Всё зависит от задачи

[Zulkar]

Совершенно верно. Все дело в программерах. На дельфи можно очень даже хорошие и большие программы делать.

Не, большие лучше не делать, там когда кода дофига на него страшно смотреть, 95 винду напоминает и эти долбаные begin end глаза мазолят. Хотя не спорю очень даже можно и большие проекты делать. Всё зависит от задачи

Нормально. Если нормально разделена сама логика программы и GUI. Ну а когда вся логика программы в TForm1.OnButton1Click, как это часто бывает - то да, лучше сразу повеситься.

[kukushka]

Можно посмотреть в сторону Java.
Для gui там есть swt. Использует Window-ые либы и работает довольно таки быстро.

По поводу самого дельфи хочу сказать что после того как я по программировал на java на дельфи возвращаться не хочется. Но приходится, по работе.

[Black_phoenix]

Читаю тему и меня радуют ваши сообщения... Delphi умирает .. Delphi отстой ...
Отстой не Delphi. Отстой это когда руки из жопы растут.

И когда жопорукие программисты хвалят одну среду а хают другую просто потому что жопорукие.

А теперь небольшое подтверждение:

http://www.weblancer...tr22/portfolio/
http://www.weblancer...?category_id=24
http://www.weblancer...?category_id=13

Советую обратить внимание на следующие проекты:

антивирус: http://www.weblancer...61799.html#item
Базы от ClamAV остальное ( движок, сканнер, DLL перехвата все на Delphi )

Работа с видео оборудованием:
http://www.weblancer...61824.html#item

Программный комплекс ( биллинг ) для управления интернет кафе
http://www.weblancer...62847.html#item
( учет трафика, базы данных, безопасность в виде переписывании msgina.dll и пр присутствуют )

Дизайнер интерфейса
http://www.weblancer...62860.html#item
Позволяет координально менять интерфейс программы, добавляя новые компоненты. Что из этого получается можно посмотреть здесь: http://phoenix-softw...o...&Itemid=116


Полностью переписанная оболочка Windows
http://www.weblancer...61812.html#item
Переделанный рабочий стол, трей, панель задач и пр. описание очень большое ( 8 месяцев работы )


И это все написано на Delphi 6 и Delphi 7 ( и создано хочу заметить, одним человеком )
А в ответ на ваши утверждения на счет того умирает ли какая то среда разработки или нет могу ответить просто. Умирает ваше умение. И заместо того чтобы сидеть и попутсту часать языками лучше бы занимались самосовершенствованием

Так же хотелось бы заметить что я не говорю что какая то среда лучше чем другая.
Можно шедевр написать на Qbasic
Ведь умение зависит не от языка программирования а от человека. И спор тут бессмыслен.

Удачи вам. Программисты интерфейсов баз данных

[xxel]

Читаю тему и меня радуют ваши сообщения... Delphi умирает .. Delphi отстой ...
Отстой не Delphi. Отстой это когда руки из жопы растут.

И когда жопорукие программисты хвалят одну среду а хают другую просто потому что жопорукие.

А теперь небольшое подтверждение:

И что из вышесказаного подтверждает нижеприведенное ?

http://www.weblancer...tr22/portfolio/
http://www.weblancer...?category_id=24
http://www.weblancer...?category_id=13

Советую обратить внимание на следующие проекты:

антивирус: http://www.weblancer...61799.html#item
Базы от ClamAV остальное ( движок, сканнер, DLL перехвата все на Delphi )

Мягко говоря неправда. На том же сайте в соседних страницах. Описание автора :
"Антивирус и все модули к нему кроме самого движка написаны на Delphi (движок на С++) "

Остальные рюшки на дельфи. Впрочем как все остальные проекты - красивое применение
DevExpress компонентов и прочих. Таких в инете как грязи.

И это все написано на Delphi 6 и Delphi 7 ( и создано хочу заметить, одним человеком )

Снова перечисление пыльных версий 2002 года как доказательство развится среды/языка?

Если уж так охото попиарить дельфи то вместо сайта неизвестного студента можно было банально вспомнить Skype.

А в ответ на ваши утверждения на счет того умирает ли какая то среда разработки или нет могу ответить просто. Умирает ваше умение. И заместо того чтобы сидеть и попутсту часать языками лучше бы занимались самосовершенствованием

Так же хотелось бы заметить что я не говорю что какая то среда лучше чем другая.
Можно шедевр написать на Qbasic
Ведь умение зависит не от языка программирования а от человека. И спор тут бессмыслен.

Удачи вам. Программисты интерфейсов баз данных

А сейчас непрограммист интерфейсов бд, постоянно занимающийся самосовершенствованием, с неумирающим умением, мастер Black_phoenix покажет нам как из дельфи 7 работать, например, с XNA. А мы посмотрит от чего зависит возможность сделать это.

[Black_phoenix]

Дальше спор считаю нецелесообразным.

Сообщение отредактировал Black_phoenix: 28.04.2009, 15:52:17

[Black_phoenix]

p.p.s
>Остальные рюшки на дельфи.

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

Сообщение отредактировал Black_phoenix: 28.04.2009, 15:53:05

[Zulkar]

p.p.s
>Остальные рюшки на дельфи.

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

Вы вообще читаете?
"Антивирус и все модули к нему кроме самого движка написаны на Delphi (движок на С++) "

По вашему движок это что? Это как раз то, что работает на Ring0, ставит хуки и прочее. Вот он не на дельфи написан.

[Black_phoenix]

> Zulkar

Вы наверное лучше автора знаете что написано на С ++ а что на Delphi ?

В данном случае проверку по сигнатурам и загрузку БД сигнатур я сделал на С++ а перехват в Ring0 реализован с помощью драйвера который написан на Delphi 3 ( так как 2 и 3 версия позволяет компилировать драйвера)

Код на С ++ сделан только для ускорения проверки. Изначально все было на Delphi.

Летом антивирус появиться в продаже.
Уже есть большие корпоративные заказчики на него, которые и профинансировали его разработку.

Спорить с вами бесполезно
Больше отвечать на сообщения не буду, лишняя трата времени. Удачи.

[dzid]

на x86_64 не работает? "Фтопку его, Кызылдур!"

[trigRemm]

задался желанием изучать Delphi 7 но после вышепрочитанного ... а что вы посоветуете для новичка - чтоб и научиться чему нить и успеть применить пока "из оборота" не вышло так сказать??...

[Black_phoenix]

Многие системные программисты привыкли считать delphi полным отстоем. Свое мнение они аргументируют тем, что компилятор генерирует слишком медленный и большой код, а средний размер пустой формы с кнопкой - 400 килобайт. Впрочем, иногда никаких аргументов и вовсе не приводится. Когда на форумах сталкиваются поклонники С++ и delphi, первые обычно кричат о супернавороченном синтаксисе и потрясающих возможностях ООП, при этом утверждая, что в системном программировании все это необходимо, а вторые - о возможностях того же ООП на дельфи, которых нет в С++, и о том, что на этом языке писать проще. Из слов и тех, и других можно заключить, что обе стороны ни про delphi, ни про c++ ничего толком не знают, и все это - пустая ламерская болтовня.

Эта статья посвящена приемам системного программирования на delphi. Она написана для тех, кто любит этот язык, хочет добиться максимальной эффективности кода и не боится вложить в свое дело определенный труд. Я покажу, как делать на дельфи то, что многие считают невозможным. Тем, кто занимается кодингом на С++, не составит труда найти целую кучу статей по оптимизации. Если же ты пишешь на delphi, ты не найдешь на эту тему ничего хорошего. Видимо, все считают, что никакой оптимизации здесь не нужно. Может быть, тебя устраивает 400-килобайтная пустая форма с кнопкой? А, ты думаешь, что это неизбежное зло, и уже давно с ним смирился? Что ж, придется немного расстроить твои нервы и развеять священные заблуждения.

Немного о генерируемом компилятором коде.

Для начала проверим утверждение, что компилятор delphi генерирует много лишнего и неэффективного кода. Для этого напишем функцию, скачивающую и запускающую файл из интернета (такие вещи обычно используют в троянах). Писать будем, естественно, с применением api. Вот что у меня получилось:

1. const
2. destfile = ′c: rojan.exe′;
3. begin
4. urldownloadtofile(nil, source, destfile, 0, nil);
5. winexec(destfile, sw_hide);
6. end;


Этот сорец я вставил в программу, скомпилировал и дизассемблировал в ida. Вот его откомментированный листинг:

1. source = dword ptr 8
2. push ebp
3. mov ebp, esp
4. push 0 ; lpbindstatuscallback
5. push 0 ; dword
6. push offset destfile ; lpcstr
7. mov eax, [ebp+source]
8. push eax ; lpcstr
9. push 0 ; lpunknown
10. call urldownloadtofilea
11. push 0 ; ucmdshow
12. push offset destfile ; lpcmdline
13. call winexec
14. pop ebp
15. retn 4
16. downloadandexecute endp
17. destfile db ′c: rojan.exe′,0

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

ООП - двигатель прогресса.

ООП - весьма модное в настоящее время направление программирования. Его цель - упростить написание программ и сократить сроки их разработки, и с нею ООП прекрасно справляется. Большинство прикладных программистов, пишущих на С++ или delphi, уже не мыслят своей деятельности без ООП. Их главный принцип - быстрее сдал программу, быстрее получил деньги. В таких условиях о какой бы то ни было оптимизации просто забывают.

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

А вот программа, написанная на vb или на vc с применением mfc, отчего-то занимает гораздо меньше места. Все потому, что великая и ужасная компания microsoft приложила к этому свою лапу. mfc и runtime-библиотеки в vb весят ничуть не меньше, просто они скомпилены в dll и входят в поставку windows, а значит, их код не приходится таскать с собой в программах. В защиту borland можно сказать, что такая возможность присутствует и в delphi. Нужно просто в настройках проекта поставить галочку build with runtime packages, тогда программа значительно уменьшится, но потребует наличия соответствующих runtime-библиотек. Естественно, эти библиотеки в поставку винды не входят, но в этом надо винить не Борланд, а монопольную политику мелкософта.





Любители ООП, желающие разрабатывать программы в визуальном режиме, могут использовать kol. Это попытка сделать что-то типа vcl, но с учетом ее недостатков. Средний размер пустой формы с кнопкой - 35 Кб, что уже лучше, но для серьезных приложений эта библиотека не подходит, так как часто глючит. Да и решение это половинчатое.

Те, кто хочет добиться действительно высокой эффективности кода, должны идти по принципиально другому пути: забыть про ООП и все, что с ним связано, раз и навсегда. Писать программы придется только на чистом api.

Виновник номер два.

Создадим в delphi пустой проект, заведомо не содержащий никакого полезного кода:
1. begin
2. end.

После компиляции в delphi 7 мы получаем экзешник размером в 13,5 Кб. Откуда?! Ведь в программе ничего нет! Ответ на этот вопрос опять поможет дать ida. Дизассемблируем экзешник и посмотрим, что он содержит. Точка входа в программу будет выглядеть так:
1.
2. start:
3. push ebp
4. mov ebp, esp
5. add esp, 0fffffff0h
6. mov eax, offset moduleid
7. call _initexe
8. ; здесь мог бы быть наш код
9. call _handlefinally
10. code ends

Весь лишний код находится в функциях _initexe и _handlefinally. Дело в том, что к каждой delphi программе неявно подключается код, входящий в состав rtl (run time library). Эта либа нужна для поддержки таких возможностей языка, как ООП, работа со строками (string) и специфичные для паскаля функции (assignfile, readln, writeln, etc.). initexe выполняет инициализацию всего этого добра, а handlefinally обеспечивает корректное освобождение ресурсов.
Сделано это, опять же, для упрощения жизни программистам, и применение rtl иногда оправданно, так как может не понизить, а повысить эффективность кода. Например, в состав rtl входит менеджер кучи, который позволяет быстро выделять и освобождать маленькие блоки памяти. По своей эффективности он в три раза превосходит системный. В плане производительности генерируемого кода работа со строками реализована в rtl тоже довольно неплохо, правда все равно, в увеличении размера файла, rtl - виновник номер два после ООП.



Уменьшаем размер.

Если минимальный размер в 13,5 Кб тебя не устраивает, то будем убирать delphi rtl. Весь код либы находится в двух файлах: system.pas и sysinit.pas. К сожалению, компилятор подключает их к программе в любом случае, поэтому единственное, что можно сделать, - удалить из этих модулей весь код, без которого программа может работать, и перекомпилить модули, а полученные dcu-файлы положить в папку с программой.

Файл system.pas содержит основной код rtl и поддержки классов, но все это мы выбросим. Минимальное содержимое этого файла должно быть таким:
1.
2. interface
3.
4. procedure _handlefinally;
5.
6. type
7. tguid = record
8. d1: longword;
9. d2: word;
10. d3: word;
11. d4: array [0..7] of byte;
12. end;
13.
14. pinitcontext = ^tinitcontext;
15. tinitcontext = record
16. outercontext: pinitcontext;
17. excframe: pointer;
18. inittable: pointer;
19. initcount: integer;
20. module: pointer;
21. dllsaveebp: pointer;
22. dllsaveebx: pointer;
23. dllsaveesi: pointer;
24. dllsaveedi: pointer;
25. exitprocesstls: procedure;
26. dllinitstate: byte;
27. end;
28.
29. implementation
30.
31. procedure _handlefinally;
32. asm
33.
34. end;
35. end.

Описания структуры tguid компилятор требует в любом случае и без нее компилировать модуль отказывается. tinitcontext понадобится линкеру, если мы будем собирать dll. handlefinally - процедура освобождения ресурсов rtl, компилятору она тоже необходима, хотя может быть пустой.

Теперь урежем файл sysinit.pas, который содержит код инициализации и завершения работы rtl и управляет поддержкой пакетов. Нам хватит следующего:
1.
2. interface
3.
4. procedure _initexe;
5. procedure _halt0;
6. procedure _initlib(context: pinitcontext);
7.
8. var
9. moduleislib: boolean;
10. tlsindex: integer = -1;
11. tlslast: byte;
12.
13. const
14. ptrtonil: pointer = nil;
15.
16. implementation
17.
18. procedure _initlib(context: pinitcontext);
19. asm
20.
21. end;
22.
23. procedure _initexe;
24. asm
25.
26. end;
27.
28. procedure _halt0;
29. asm
30.
31. end;
32. end.

initexe - процедура инициализации rtl для exe-файлов, initlib - для dll, halt0 - завершение работы программы. Все остальные лишние структуры и переменные, которые пришлось оставить, необходимы компилятору. Они не будут включаться в выходной файл и никак не повлияют на его размер.

Теперь положим эти два файла в папку с проектом и скомпилируем их из командной строки:
dcc32.exe -q system.pas sysinit.pas -m -y -z -$d- -o

Избавившись от rtl, мы получили экзешник размером в 3,5 Кб. Борландовский линкер создает в исполняемом файле шесть секций, они выравниваются по 512 байт, к ним плюсуется pe-заголовок, что и дает эти 3,5 Кб.

Но вдобавок к малому размеру мы получаем и определенные затруднения, так как теперь не сможем использовать заголовочные файлы на winapi, идущие с delphi. Вместо них придется писать свои. Это нетрудно, поскольку описания используемых api можно брать из борландовских хедеров и переносить в свои по мере необходимости.

Если в составе проекта есть несколько pas-файлов, линкер для выравнивания кода вставит в него пустые участки, и размеры опять увеличатся. Чтобы этого избежать, нужно всю программу, включая определения api, помещать в один файл. Это весьма неудобно, поэтому лучше воспользоваться директивой препроцессора $include и разнести код на несколько inc-файлов. Тут может встретиться еще одна проблема - повторяющийся код (когда несколько inc-файлов подключают один и тот же inc) компилятор в таких случаях компилировать откажется. Выйти из положения можно, воспользовавшись директивами условной компиляции, после чего любой inc-файл будет иметь вид:
1. {$define win32api}
2. // здесь идет наш код
3. {$endif}


Таким образом, можно писать без rtl достаточно сложные программы и забыть о неудобствах.


Можно еще меньше!

Наверняка минимальный размер экзешника в 3,5 Кб удовлетворит не всех. Что ж, если постараться, можно ужать его еще в несколько раз. Для этого нужно отказаться от удобств работы с борландовским линкером и собирать исполнимые файлы линкером от microsoft. К сожалению, здесь нас ждет одна загвоздка. Мелкософтовский линкер использует в качестве основного рабочего формата coff, но может понимать и интеловский omf. Однако программисты Борланда (видать, нарочно) в версиях delphi выше третьей изменили генерируемый формат obj-файлов так, что теперь он несовместим с intel omf. То есть теперь существуют два вида omf: intel omf и borland omf. Программы, способной конвертировать объектные файлы из формата borland omf в coff или intel omf, я не нашел. Поэтому придется использовать компилятор от delphi 3, который генерирует стандартный объектный файл intel omf. Импорт используемых api нам тоже придется описывать вручную, причем достаточно необычным способом. Для начала возьмем библиотеку импорта user32.lib из состава visual c++ и откроем ее в hex-редакторе. Имена функций в ней имеют вид "_messageboxa@16", где после @ идет размер передаваемых параметров. Следовательно, объявлять функции мы будем таким образом:
Попробуем теперь написать helloworld как можно меньшего размера. Для этого создаем проект такого типа:
1.
2. interface
3.
4. procedure start;
5.
6. implementation
7.
8. function messageboxa(hwnd:cardinal;lptext,lpcaption:pchar;utype:cardinal): integer;stdcall;external′user32.dll′ name ′_messageboxa@16′;
9.
10. procedure start;
11. begin
12. messageboxa(0, ′hello world!′, nil, 0);
13. end;
14. end.

Тип модуля unit нужен для того, чтобы компилятор генерировал в объектном файле символьные имена объявленных процедур. В нашем случае это будет процедура start - точка входа в программу. Теперь компилируем проект следующей строкой:
dcc32.exe -jp -$a-,b-,c-,d-,g-,h-,i-,j-,l-,m-,o+,p-,q-,r-,t-,u-,v-,w+,x+,y- helloworld.pas

Новый файл helloworld.obj открываем в hex-редакторе и смотрим, во что превратилась наша точка входа. У меня получилось start$qqrv. Это имя нужно указать как точку входа при сборке исполнимого файла. И наконец, выполним сборку:
link.exe /align:32 /force:unresolved /subsystem:windows /entry:start$qqrv helloworld.obj user32.lib /out:hello.exe


В результате мы получаем работающий helloworld размером в 832 байта! Я думаю, что этот размер удовлетворит любого. Попробуем теперь дизассемблировать этот файл в ida и поискать лишний код:
1. ; char text[]
2. text db ′hello world!′,0
3. public start
4. start proc near
5. push 0 ; utype
6. push 0 ; lpcaption
7. push offset text ; lptext
8. push 0 ; hwnd
9. call messageboxa
10. retn
11. start endp

Ни байта лишнего кода! Покажи этот пример всем, кто любит говорить о большом размере программ, написанных на дельфи, и понаблюдай за их выражением лица - это прикольно . Самые упорные промычат: [А... Э... Все равно дерьмо!], но уже никто ничего не скажет по существу. А самые продвинутые спорщики приведут последний аргумент - на delphi нельзя написать драйвер режима ядра для windows nt. Ничего... сейчас и они присоединятся к проигравшим .


Пишем драйвер на delphi.

О том, как по нашей методике сделать невозможное - написать на delphi драйвер режима ядра, даже есть статья на rsdn, и всем интересующимся я рекомендую ее прочитать. Здесь же я приведу пример простейшего драйвера и содержимое make.bat для его сборки.
1.
2. interface
3.
4. function driverentry(driverobject, registrypath: pointer): integer; stdcall;
5.
6. implementation
7.
8. function dbgprint(str: pchar): cardinal; cdecl; external ′ntoskrnl.exe′ name ′_dbgprint′;
9. function driverentry(driverobject, registrypath: pointer): integer;
10.
11. begin
12. dbgprint(′hello world!′);
13. result := -1;
14. end;
15. end.

Файл make.bat:
dcc32.exe -jp -$a-,b-,c-,d-,g-,h-,i-,j-,l-,m-,o+,p-,q-,r-,t-,u-,v-,w+,x+,y- driver.pas
link.exe /driver /align:32 /base:0x10000 /subsystem:native /force:unresolved /entry:driverentry$qqspvt1 driver.obj ntoskrnl.lib /out:driver.sys

Для компиляции нам понадобится файл ntoskrnl.lib из ddk. Мы получим драйвер размером в килобайт, который выводит сообщение [hello world] в отладочную консоль и возвращает ошибку, а потому не остается в памяти и не требует определения функции driverunload. Для запуска драйвера используй kmdmanager от four-f. Увидеть результаты его работы можно в софтайсе или dbgview.

Главная проблема, из-за которой на delphi нельзя писать полноценные драйвера, - отсутствие ddk. Для написания драйверов нужны заголовочные файлы на api-ядра и описания большого количества системных структур. Все это богатство есть только для С (от microsoft) и для masm32 (от four-f). Есть слух, что ddk для паскаля уже существует, но автор продает его за деньги и сильно этот факт не афиширует. Думаю, когда-нибудь все-таки найдутся энтузиасты, которые перепишут ddk на паскаль и выложат для всеобщего использования. Другой проблемой является то, что большинство примеров, связанных с системным программированием, написаны на си, поэтому на каком бы языке ты ни писал свои программы, си знать придется. Это, конечно, не означает, что придется изучать С++ в полном его объеме. Для понимания системных программ хватит базовых знаний синтаксиса, все остальное же используется только в прикладных программах, которые нас совершенно не интересуют.

[Big Joe]

А авторитет Delphi продукты от НАТ и ИТРС подпортили не хило))) Я видел как у них ведется разработка. Пишет один, затем уходит из проекта. Продолжает другой, затем тот увольняется и продолжает новенький студент, которому не в кайф капаться в чужом коде и разбирать класс-ы предшественника и пишет свои, затем получается некий мусор из за которого винят потом среду(имхо)

[г-н Набэсима]

ИМХО, написАть плохую программу можно на любом языке (зависит от драйвера "прямые руки").
Так что по теме топика - альтернатива Delphi - это то, на чем умеешь хорошо прогать.
Я, например, уже лет 12 на делфях сижу и для своих программ ни разу не столкнулся с ситуацией,
когда среда не позволяет что-то сделать. Опять же, в основном, делаю оболочки для БД, а для
этих целей Делфи - самое оно.

[hes]

А авторитет Delphi продукты от НАТ и ИТРС подпортили не хило))) Я видел как у них ведется разработка. Пишет один, затем уходит из проекта. Продолжает другой, затем тот увольняется и продолжает новенький студент, которому не в кайф капаться в чужом коде и разбирать класс-ы предшественника и пишет свои, затем получается некий мусор из за которого винят потом среду(имхо)

Про ИТРС это факт. Хотя изначально там были хорошие программеры. Ушли практически ВСЕ они.

[Random]

сам работал в ИТРС..
то что говорит Биг Джо - факт!

А авторитет Delphi продукты от НАТ и ИТРС подпортили не хило))) Я видел как у них ведется разработка. Пишет один, затем уходит из проекта. Продолжает другой, затем тот увольняется и продолжает новенький студент, которому не в кайф капаться в чужом коде и разбирать класс-ы предшественника и пишет свои, затем получается некий мусор из за которого винят потом среду(имхо)

Про ИТРС это факт. Хотя изначально там были хорошие программеры. Ушли практически ВСЕ они.

один Аха там остался
Пирог тоже ушел оттуда..

[hes]

сам работал в ИТРС..
то что говорит Биг Джо - факт!

А авторитет Delphi продукты от НАТ и ИТРС подпортили не хило))) Я видел как у них ведется разработка. Пишет один, затем уходит из проекта. Продолжает другой, затем тот увольняется и продолжает новенький студент, которому не в кайф капаться в чужом коде и разбирать класс-ы предшественника и пишет свои, затем получается некий мусор из за которого винят потом среду(имхо)

Про ИТРС это факт. Хотя изначально там были хорошие программеры. Ушли практически ВСЕ они.

один Аха там остался
Пирог тоже ушел оттуда..

это очень очень нехорошо. нда, Рус лажает.

[Random]

Рус щас отошел от руководства.
Сейчас там рулит другой чел.

[hes]

Рус щас отошел от руководства.
Сейчас там рулит другой чел.

как все грустно. мельчает итрц)

нащет сабжа, есть в мире люди, которые могут писать на чистом винапи в дельфе - это не фантастика, все вполне реально, без всяких VCL и тп. сам к ним не отношусь потому что круг интересов и текущая среда программирования не те) насчет того что дельфи не пригоден - категорически не согласен - есть банковская система колвир - http://www.colvir.com/ вполне конкурентноспособная банковская система, работающая во многих банках как России так и в Казахстане.

Сообщение отредактировал hes: 01.06.2009, 14:21:51