AKATAN, браво 

Java нынче в институтах учат, эти ТРОЯ и на Java с тем же успехом писать будут.



а разве Delphi дешевле Java?

Уважаемый, такой фирмы давно нет   

Интересно, а кто нибудь в Европе или США заказывает софт на Делфи?

заказывают как правило решение, инструмент не важен.

Но покупают исходный код.

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

AKATAN, все бы это хорошо, вот только с каких торрентов ты будешь скачивать Delphi, чтобы это было дешевле?

Клиентам нужны решения, которые будут интегрироваться с решениями, которые у них уже есть. Поэтому важен и язык разработки и исходный код. Возможно на территории пост-советского пространства всё по другому, но наша компания работает с клиентами в основном из США, поэтому поставляется так же большая часть исходного кода и документация. Про проекты на Делфи не слышал.




Ну не верю я что такое сообщение мог написать руководитель проекта 

И потом, для таких "проектов" наверное можно и VB6 использовать   
Калькулятор пишется одинаково на любом ЯП, но если это серьёзный проект, который поддерживается и расширяется, то Делфи тут, уж простите 

Чем плох Delphi с точки зрения "поддержки и расширения"?

Keeper89, ну на такие вопросы даже отвечать не хочется, так как приходится рассказывать что солнце излучает свет и тепло  . Давай лучше сделаем всё более наглядно. Ты сделаешь, для примера, очень простое приложение, которое состоит из основного проекта, который будет компилироваться в *.exe и нескольких дополнительных проектов, которые будут компилироваться в *.dll. В проектах, которые будут компилироваться в dll, будут определены классы, которые нужно будет использовать в основном *.exe проекте. Вот тебе и расширяемость. Ведь согласись, модульность - это очень важная часть расширяемости. Ну а поддержка вытекает из всего этого   

Это сообщение отредактировал(а) Rohoss - 5.6.2011, 23:57

Вот я не поленился, и раз уж на то пошло, сделал расширяемый калькулятор   
Конечно, пример надуманный и функционал мог бы быть куда серьёзней, но что у нас есть:
Сборка Contracts. Название говорит само за себя, тут определено два интерфейса и один класс




Как видите, кода используется очень мало   

Дальше, у нас есть основное приложение, здесь есть реализация интерфейса IOperationContainer


и сама инициализация механизма состыковки модулей и привязки к гую


На этом всё, наш калькулятор готов, правда функционал калькулятора у нас ещё не готов, но он будет содержатся в других модулях   
Что интересно, в проекте у нас есть папка Modules, там мы и будем содержать наши модули, в которых хранится реализация логики подсчётов. Что нужно для создания модуля? Всё предельно просто, покажу на примере создания модуля для суммирования двух чисел.
Итак, нам нужно создать проект, в проект добавляем ссылку на сборку System.ComponentModel.Composition и соответственно на наш контракт Contracts. Добавляем новый класс, который будет реализовывать интерфейс IOperation, и метим атрибутом [Export(typeof(IOperation))]. Это всё что нужно, далее логика подсчёта сумы, вот весь код данного модуля

Вот и всё. Теперь, запустив построенное приложение, мы увидим три текстовых поля (два для ввода данных, одно для результата), и список кнопок. Каждая кнопка будет содержать текст (Description модуля) и будет вызывать логику обработки данных. При чём, нам не нужно добавлять кнопку вручную, всё происходит автоматически. Мы создаём модуль, компилируем в dll и бросаем в папку Modules. При чём в одной dll может быть сколько угодно модулей, так же как и dll в папке Modules может быть сколько угодно   
Проект приаттачел. Необходимы, VS210 + .Net 4.0

Просьба повторить всё так же легко и культурно на Делфи

Добавлено через 14 минут и 24 секунды
И давайте в дальнейшем поменьше флейма и побольше кода и доказательств. Я когда то был делфистом, а теперь дотнетчик. И пускай я был не крутым делфистом, а сейчас я не крутой дотнетчик, но обе технологии я на себе испытал, и сделал окончательный и бесповоротный вывод. В общем после дотнета использовать Делфи ни малейшего желания нет   

Это сообщение отредактировал(а) Rohoss - 5.6.2011, 23:41

Присоединённый файл ( Кол-во скачиваний: 7 )
 DelphiVsNet.zip 111,52 Kb

Для тех, кому не хочется качать весь проект, может скачать только приложение. Нужен .Net 4.0    


Это сообщение отредактировал(а) Rohoss - 5.6.2011, 23:56

Присоединённый файл ( Кол-во скачиваний: 4 )
 DelphiVsNetApp.zip 8,97 Kb

Для тех кто не верит сделал простенькую dll, которую вы можете бросить в папку Modules, будь это приложение или проект, и сами можете наблюдать изминения   



Это сообщение отредактировал(а) Rohoss - 6.6.2011, 00:14

Присоединённый файл ( Кол-во скачиваний: 3 )
 SubtractOperation.zip 1,93 Kb

и чооо

Rohoss, 

Не удачный пример. Емнип, в Делфях подобная шнаяга реализуется с той же непринужденностью.


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

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

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

Это сообщение отредактировал(а) Zloxa - 6.6.2011, 09:48