Будущее Делфи?

← →
DMM (2009-04-01 23:33) [0]

Всем привет.
Давно уже учу Делфи, много чего писал и пишу... И тут задумался: а есть ли у этого языка будущее? Одна корпорация от него отказалась, с другой неизвестно что твориться... Как вы думаете? Есть будущее?

← →
Anatoly Podgoretsky © (2009-04-01 23:37) [1]

> DMM (01.04.2009 23:33:00) [0]

Еще один гробокопатель.

← →
жж (2009-04-01 23:37) [2]

нет

← →
tesseract © (2009-04-01 23:43) [3]

> Одна корпорация от него отказалась, с другой неизвестно
> что твориться..

С таким настроением лучше учить 1С. Нормальные организаторы ценят результат, а не платформу.

← →
DVM © (2009-04-02 01:07) [4]

> Давно уже учу Делфи

Это что стихотворение или заклинание? Учить надо не делфи, а учиться программировать.

← →
turbouser © (2009-04-02 01:09) [5]

> DMM (01.04.09 23:33)

Будущего нет. И завтра не будет.

← →
Кто б сомневался © (2009-04-02 01:17) [6]

Ни у одного языка нет гарантированного будущего.
К примеру тот же С++, которому пророчили, уже почти загнулся. C# пришел.

← →
Германн © (2009-04-02 01:46) [7]

> К примеру тот же С++, которому пророчили, уже почти загнулся.

Иногда лучше всё-таки посомневаться.

← →
kaif (2009-04-02 02:22) [8]

Помнится, несколько лет назад выражение "язык Дельфи" вызывало гневные протесты и обвинения в заведомом ламерстве.
Правильно было говорить Object Pascal.
А сегодня это название уже почти прижилось.
Неисповедимы пути языка человеческого...

← →
Eraser © (2009-04-02 02:27) [9]

> [8] kaif (02.04.09 02:22)

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

← →
Игорь Шевченко © (2009-04-02 02:46) [10]

kaif (02.04.09 02:22) [8]

Согласно последнему постановлению ВЦСПС

← →
KilkennyCat © (2009-04-02 05:14) [11]

Мы все умрем.

← →
test © (2009-04-02 06:58) [12]

Учи Ruby on rails он новый, и не так быстро умрет!

DVM © (02.04.09 01:07) [4]
+100

← →
@!!ex © (2009-04-02 07:47) [13]

> [0] DMM (01.04.09 23:33)

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

← →
Alkid © (2009-04-02 10:58) [14]

> Кто б сомневался © (02.04.09 01:17) [6]
>
> Ни у одного языка нет гарантированного будущего.
> К примеру тот же С++, которому пророчили, уже почти загнулся.
> C# пришел.

Слухи о загибании С++ сильно преувеличены :) Его существенно потеснили, но до смерти ещё ой как далеко.

← →
KSergey © (2009-04-02 11:47) [15]

> Alkid © (02.04.09 10:58) [14]
> Слухи о загибании С++ сильно преувеличены :) Его существенно
> потеснили, но до смерти ещё ой как далеко.

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

← →
Ega23 © (2009-04-02 11:49) [16]

Нет у Delphi будущего. Вообще нет. Надо эту простую истину донести во все школы и ВУЗы.
И наступит нам щщастье. :)

← →
test © (2009-04-02 13:24) [17]

Ega23 © (02.04.09 11:49) [16]
И учить программированию в этих заведениях на Эрланге.

← →
Ega23 © (2009-04-02 13:43) [18]

> на Эрланге.

Cobol всему голова!

← →
Anatoly Podgoretsky © (2009-04-02 15:51) [19]

> Eraser (02.04.2009 2:27:09) [9]

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

← →
Anatoly Podgoretsky © (2009-04-02 15:51) [20]

> KilkennyCat (02.04.2009 5:14:11) [11]

Прошу ко мне это не применять.

← →
Городской Шаман (2009-04-02 16:24) [21]

> Alkid © (02.04.09 10:58) [14]
>
> Слухи о загибании С++ сильно преувеличены :) Его существенно
> потеснили, но до смерти ещё ой как далеко.

Не потеснили. Просто для ниши корпоративного ПО были созданы более соответствующие технологии как Java и .ПТУ.

C++ мощный и удобный язык, но не походит для студенческо-бардачной разработки. А вот то же приложение написанное студентами на .ПТУ, криво, глючно и тормознуто, но как-то работать будет. Что чаще всего и достаточно для бизнеса.

← →
Eraser © (2009-04-02 16:27) [22]

> [21] Городской Шаман (02.04.09 16:24)

> Что чаще всего и достаточно для бизнеса.

а для чего вообще нужны программы? программирование ради программирования что ли?

← →
Кто б сомневался © (2009-04-02 16:30) [23]

> C++ мощный и удобный язык, но не походит для студенческо-
> бардачной разработки.

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

← →
Кто б сомневался © (2009-04-02 16:32) [24]

Никто не говорит что он плохой, или слабый, - просто MS сменили политику в этом плане. Просто подчеркиваю факт.

← →
DVM © (2009-04-02 16:32) [25]

В Unix С++ живет и здравствует и никакими C# там и не пахнет.

← →
Городской Шаман (2009-04-02 16:35) [26]

> Eraser © (02.04.09 16:27) [22]
>
> > [21] Городской Шаман (02.04.09 16:24)
>
> > Что чаще всего и достаточно для бизнеса.
>
> а для чего вообще нужны программы? программирование ради
> программирования что ли?

Нет. Программы нужны для удовлетворения потребностей пользователя. Но если у пользователя в корпорации нет выбора какой программой пользоваться, то у "персонального" пользователя (как малые бизнесы или домашнее ПО) выбор есть большой. И этот пользователь подбирает под себя то ПО, которое его наиболее устраивает по всем параметрам. Здесь он считает каждую свою копейку и выбирает лучшее. И выбор, чаще всего не в пользу приложений на .ПТУ.

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

← →
test © (2009-04-02 16:38) [27]

Городской Шаман (02.04.09 16:35) [26]
У мелких пользователей может быть любой зоопарк на машинах, в корпорация утвержденный перечень существует. Караван идет с той скоростью с которой плететься самый медленный верблюд в караване.

← →
Городской Шаман (2009-04-02 16:39) [28]

> test © (02.04.09 16:38) [27]

Вот именно, там где для корпорации может быть смерть, для ЧП золотые горы.

← →
@!!ex © (2009-04-02 16:54) [29]

> [25] DVM © (02.04.09 16:32)
> В Unix С++ живет и здравствует и никакими C# там и не пахнет.

В Unix на удивление много чистого С и Объектного.

← →
Palladin © (2009-04-02 17:10) [30]

> DVM © (02.04.09 16:32) [25]

в Юникс, в первую и самую главную очередь, C

← →
Кто б сомневался © (2009-04-02 17:16) [31]

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

Речь идет о тенденции. В ближайшие лет 15 думаю все измениться окончательно.

← →
Ega23 © (2009-04-02 17:23) [32]

> В ближайшие лет 15 думаю все измениться окончательно.

Раньше. Вот БАК запустят - и КС сразу настанет.

← →
Kostafey © (2009-04-02 17:27) [33]

> [16] Ega23 © (02.04.09 11:49)
Нет у Delphi будущего. Вообще нет. Надо эту простую истину донести во все школы и ВУЗы.
И наступит нам щщастье. :)

А в вузах и так уже отказываются от того, чтобы его
преподавать.
Правда, мотивируется это весьма забывно. Мол,
сейчас С# и java прет, так Delphi же ни к чему учить, лучше уж
тогда С++, язык - то тот же (почти цитировал).
...почти смешно.

> [12] test © (02.04.09 06:58)
> Учи Ruby on rails он новый, и не так быстро умрет!

Вопрос на сколько он удобен в вебе.
Действительно лучше классического JEE?
А то и сам в его сторону временами поглядываю...

> [15] KSergey © (02.04.09 11:47)
> хм, мне думалось, что на шарп в основном перелезли с дельфи,
> джавы, визуал бейсика. С плюсов - ну разыве что кто-то
> гемороился на плюсах не по делу.

Не, с поюсов тоже переходили.

> [21] Городской Шаман (02.04.09 16:24)
> C++ мощный и удобный язык, но не походит для студенческо-
> бардачной разработки. А вот то же приложение написанное
> студентами на .ПТУ, криво, глючно и тормознуто, но как-то
> работать будет. Что чаще всего и достаточно для бизнеса.

Это конечно аргумент, да. Но не единственный и не главный.

← →
test © (2009-04-02 17:28) [34]

Кто б сомневался © (02.04.09 17:16) [31]
Изменится в чем?
Ты знаеш как будет развиваться отрасль в целом?

← →
test © (2009-04-02 17:29) [35]

Kostafey © (02.04.09 17:27) [33]
Я про него прочитал не совсем понял зачем второй PHP, ИМХО одно достаточно.
Во всяком случае мнение у меня таколе сложилось.

← →
Игорь Шевченко © (2009-04-02 17:30) [36]

Kostafey © (02.04.09 17:27) [33]

> А в вузах и так уже отказываются от того, чтобы его
> преподавать.

А в вузах конкретные языки и не надо преподавать. Паскаль (классический) вполне подходит для изучения разработки и анализа алгоритмов.

← →
Kostafey © (2009-04-02 17:37) [37]

> [35] test © (02.04.09 17:29)

Судя по тому что написано в википедии,
Ruby создавался как мегасовременный и
продуманный язык, который учел все достоинства
и недостатки предыдущих. Посему в какой-то
момент загорелся идеей изучить, тем более, что
есть реализация на java.
А Ruby on rails - опять-таки мегасовременный
фреймворк для веба, где, мол все уже есть.

Ясно, спасибо за комментарии. Теперь поостыл :)

← →
Kostafey © (2009-04-02 17:40) [38]

> [36] Игорь Шевченко © (02.04.09 17:30)

Ну по-моему это две большие разницы.
Либо учить Pascal, С/С++;
либо же С#, Java, да и пожалуй даже Delphi.
Философия языков разная.

А алгоритм - это да, он и в Африке алгоритм,
согласен :)

← →
test © (2009-04-02 17:41) [39]

Kostafey © (02.04.09 17:37) [37]
Я про него примерно тоже, примерно там же читал, чтобы язык оценивать надо по нему хотя бы книгу прочитать пару проектов на нем сделать пока что у меня такого опыта нет.

← →
test © (2009-04-02 17:42) [40]

Kostafey © (02.04.09 17:40) [38]
Учат программирование, язык только как иллюстрация.

← →
Городской Шаман (2009-04-02 18:20) [41]

> Kostafey © (02.04.09 17:40) [38]
>
> А алгоритм - это да, он и в Африке алгоритм,
> согласен :)

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

А для алгоритмов достаточно книжечки на 200 страниц, чтобы бы быть профи. Алгоритмы больше все таки математика, чем программирование.

← →
DVM © (2009-04-02 19:29) [42]

> Городской Шаман (02.04.09 18:20) [41]

> А для алгоритмов достаточно книжечки на 200 страниц, чтобы
> бы быть профи

Сразу Кнут с его томами почему то вспомнился.

← →
Кто б сомневался © (2009-04-02 19:38) [43]

> test © (02.04.09 17:28) [34]
>
> Кто б сомневался © (02.04.09 17:16) [31]
> Изменится в чем?
> Ты знаеш как будет развиваться отрасль в целом?

Нет не знаю, но увидеть тендецию - к чему все идет, думаю любой сможет.
И вероятность здесь очень высока.

← →
Копир © (2009-04-02 19:44) [44]

>kaif (02.04.09 02:22) [8] :
>Eraser © (02.04.09 02:27) [9] :
>Игорь Шевченко © (02.04.09 02:46) [10] :

Я тоже тащусь от "языка Delphi".

Ну что поделать, когда визуальные компоненты и библиотека
RX в каком-то смысле действительно заменяет "язык".

Кликнул мышкой и стал календарь.
Кликнул дважды - глядишь и тут же сервер на продажу.

Молодые респонденты или никогда не знали (скорее всего),
что такое язык программирования "Pascal".

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

А чем не язык?
Как утверждал Гёдель (я извиняюсь, фамилия избитая и популярная),
как утверждал Курт Гёдель, - язык это совокупность общеизвестных
понятий (это я так, по-своему, вульгарно выразил).

В этом смысле ув.господин DMM прав.

← →
Игорь Шевченко © (2009-04-02 19:49) [45]

Kostafey © (02.04.09 17:40) [38]

Философия одна и та же. Найди, плз, 10 отличий именно в философии языка между C/C++, Delphi, Java и C#

← →
Игорь Шевченко © (2009-04-02 19:50) [46]

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

Это как ?

← →
Копир © (2009-04-02 20:04) [47]

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

От арабского языка, например.

Первое отличие: это своеобразие иероглифов.

Совокупность Begin ... End сумеет заметить только
очень продвинутый переводчик.

Второе отличие в том, что можно сколько угодно взывать
к Аллаху в СМИ. Эти взывания, наверное (или возможно)
не приведут ни к какому действию.

Взывание программиста обязательно приведут к действию.
Иначе само задание не имеет смысла.

Действия программиста и в 90-е, и в нулевые годы, и сейчас,
почти в десятые годы нового века. Они всегда сопряжены с конкретной
задачей. С бухгалтерской, с купеческой, с хакерской, с буржуйской...

Не нам судить.

Программисту платят деньги.
Он реализует проект, который был заказан.

Какие проблемы?

← →
TUser © (2009-04-02 20:29) [48]

> Ega23 © (02.04.09 17:23) [32]
>
>
> > В ближайшие лет 15 думаю все измениться окончательно.
>
>
> Раньше. Вот БАК запустят - и КС сразу настанет.
>

сам Хиггс мешает

http://elementy.ru/news?newsid=431042

:)

оффтопик: Олег, а ты аську читаешь?

← →
Alkid © (2009-04-02 20:31) [49]

> Городской Шаман (02.04.09 16:24) [21]
> Не потеснили. Просто для ниши корпоративного ПО были созданы
> более соответствующие технологии как Java и .ПТУ.

Потеснили. В качестве примера приведу тот факт, что прошлая версия продукта, разрабатываемого в нашем отделе была написана на 100% на С++, а нынешнюю версию разрабатывают на C#.

> C++ мощный и удобный язык, но не походит для студенческо-
> бардачной разработки. А вот то же приложение написанное
> студентами на .ПТУ, криво, глючно и тормознуто, но как-то
> работать будет. Что чаще всего и достаточно для бизнеса.

Не вижу разницы в бардачной разработке на С++ и на C#, с той лишь разницей, что на С++ будет AV и утечки памяти, а на C# будет NullReferenceException и не будет утечки памяти. Хороший же код на обоих языках требует высокой квалификации разработчиков.

← →
blackman © (2009-04-02 20:38) [50]

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

Копир © (02.04.09 20:04) [47]
Программисту платят деньги. Он реализует проект, который был заказан.
Какие проблемы?
Никаких, кроме упорного труда.

← →
Копир © (2009-04-02 20:50) [51]

>blackman © (02.04.09 20:38) [50] :

Юрий, я понял и проникся.

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

← →
Городской Шаман (2009-04-02 20:54) [52]

> Игорь Шевченко © (02.04.09 19:50) [46]

Ну например в C++ нет делегатов(замыканий) на уровне языка (есть сторонний плагин на templat-ах). И вы видели как спроектирована MFC с её картой сообщений и прочими извратами? Самый яркий пример.

← →
Alkid © (2009-04-02 21:03) [53]

> Копир © (02.04.09 20:04) [47]
> Программисту платят деньги.
> Он реализует проект, который был заказан.
>
> Какие проблемы?

Проблема в том, что многие программисты страдают технофетишизмом, фанатично отстаивая достоинства излюбленных технологий и так же отметая "еретические" технологии. И забывают, что причины успеха или неуспеха продуктов мало связаны с технологиями.

← →
Kostafey © (2009-04-02 21:25) [54]

> [45] Игорь Шевченко © (02.04.09 19:49)
>Философия одна и та же. Найди, плз, 10 отличий именно в философии языка между C/C++, Delphi, Java и C#

10 отличий не потяну. Лишь 2-3 :).

Ну для меня ключевое отличие - это работа со
ссылочными типами.
В С++ все ссылки, указатели описывается явно.
В свое время переходя на Java сначала было
непривычно. Все (за исключением базовых типов) -
есть ссылки.

Другое ключевое отличие Java/C# vs С/С++ это
крайне строгая типизация.
Delphi/Pascal тут где-то по середине будет.

Еще неприятность - невозможно передать функцию
в качестве параметра. В С++ и Pascal это враз.

← →
Kostafey © (2009-04-02 21:27) [55]

> [44] Копир © (02.04.09 19:44)
> [47] Копир © (02.04.09 20:04)

<offtop>
Что курим? Я тоже так хочу! :)
</offtop>

← →
@!!ex © (2009-04-02 21:27) [56]

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

Это немножко заблуждение.
Пример MFC и VCL. VCL грамотно реализовать в рамках C++ насколько я понимаю нельзя(билдер не в счет, там вообще непонятно что за язык, адская смесь какая-то)

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

← →
AndreyV © (2009-04-02 21:35) [57]

> [48] TUser © (02.04.09 20:29)
> > Раньше. Вот БАК запустят - и КС сразу настанет.
>
> сам Хиггс мешает
> http://elementy.ru/news?newsid=431042
> :)

Славные грибочки уродятся. Сотрудники ЦЕРН решили сами продегустировать выращенный к 1-му апреля пробный урожай.:)

← →
blackman © (2009-04-02 21:55) [58]

AndreyV © (02.04.09 21:35) [57]
Апрель наступил и это есть хорошо!
Песня Булата Окуджавы такая есть
Мама, мама, это я дежурный. Я дежурный по апрелю
http://articles.org.ru/cn/showdetail.php?cid=5553
Это лучше чем спор о будущем :)

← →
Alkid © (2009-04-02 22:13) [59]

> @!!ex © (02.04.09 21:27) [56]
> Это немножко заблуждение.
> Пример MFC и VCL. VCL грамотно реализовать в рамках C++
> насколько я понимаю нельзя(билдер не в счет, там вообще
> непонятно что за язык, адская смесь какая-то)

Во-первых, обоснуй.
Во-вторых, VCL - это тоже технология. Использование VCL не гарантирует, что программа получится лучше, чем программа с MFC.

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

Не спорю, выбор технологии имеет значение, но он не обуславливает успех.
А некоторые тут (не буду пальцем показывать), утверждают, что если программа пишется на С++ - то это означает, что программа серьезная и качественная. А если на .NET, то не иначе как студенческая поделка.

← →
oxffff © (2009-04-02 22:16) [60]

> Alkid © (02.04.09 20:31) [49]
> Не вижу разницы в бардачной разработке на С++ и на C#, с
> той лишь разницей, что на С++ будет AV и утечки памяти,
> а на C# будет NullReferenceException и не будет утечки памяти.

Это не правда.

> Хороший же код на обоих языках требует высокой квалификации
> разработчиков.

Я бы сказал, что написать хороший код на .NET нужно очень очень очень сильно постараться. Поскольку достижимость объектов не всегда очевидна.
Создал объект, создал делегат на его метод, передал его(делегат) другому объекту. Вызвал как ты(пользователь) думаешь явный финализатор.
Прибил на него ссылку. Но другая ссылка то на него висит через делегат.
Забыл удалить из списка делегатов. Вот тебе не mem leak, а хуже.
Повисший кусок памяти, + нет никакого AV, если конечно метод обернутый в делегат не проверит is disposed.
А теперь скажи много так делать будут, проверять is disposed?

Минус первый.
Разработчик должен помнить куда он что передал. И не дай бог. Чтобы переданный объект ктонибудь не клонировал(а если мы клонируем тот самый делегат, то оследить будет ой как сложно, только спец. средства которых что-то много стало появляться для .NET)

Минус второй.
Для того чтобы сделать код безопасным придется повтрять в каждом коде метода IF is disposed {raise exception(Finalized object state")};
Интересно как скоро они добавят это в стандарт. В качестве каконибудь атрибута класса. По типу при генерации native кода метода,если у класса есть атрибут GenerateCheckForDisposedState, добавить предикат на проверку валидности.
Я могу даже эту идею им продать. Если никто из .ПТУ разработчиков об этом еще не догадался. IMHO.

← →
Alkid © (2009-04-02 22:23) [61]

> oxffff © (02.04.09 22:16) [60]
> Это не правда.

Конечно неправда :) На .NET можно устроить утечку памяти, на C# можно даже AV сбацать, благо unsafe никто не отменял. Но в общем и целом утечка памяти для .NET приложений - это очень редкая птица.

> Я бы сказал, что написать хороший код на .NET нужно очень
> очень очень сильно постараться. Поскольку достижимость объектов
> не всегда очевидна.

Может быть я не занимался столь сложными и запутанными программами на C#, которые тебе приходилось писать, но подобных проблем у меня ни разу не возникло.

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

← →
Internal Tracking (2009-04-02 22:27) [62]

> > > Раньше. Вот БАК запустят - и КС сразу настанет.
> >
> > сам Хиггс мешает
> > http://elementy.ru/news?newsid=431042
> > :)

Первое апреля. Блин а я поверил....

← →
oxffff © (2009-04-02 22:33) [63]

> Alkid © (02.04.09 22:23) [61]
>
> Может быть я не занимался столь сложными и запутанными программами
> на C#, которые тебе приходилось писать, но подобных проблем
> у меня ни разу не возникло.

Приветствую тебя. :)
Несмотря на то, что у меня есть и оба издания Рихтера по .NET, которые я прочитал и ECMA 335, ECMA 334, которые я тоже читал в рамках общего развития и читал также Expert .NET IL Assembler также оба.
Я скажу честно, работа с С#, Nemerle и другими .NET языками меня пока обошли стороной.
IL Asm и IL Dasm смотрел. Интересно.

Я сейчас больше как то по ABAP.

Хочу отметить, что в C# некоторые конструкции в плане выразительности меня очень очень сильно привлекают.
И я бы желал такое уже в Delphi сейчас.
А также не generics, а concepts из следующего стандарта по С++
в native Delphi.

← →
ZeroDivide © (2009-04-02 22:38) [64]

Delphi - фарева!

← →
oxffff © (2009-04-02 22:42) [65]

> А также не generics, а concepts из следующего стандарта
> по С++
> в native Delphi.

А об этом на мой вопрос один из разработчиков компилятора Delphi ответил, (я привел ему доводы по поводу недостатков generics для native платформ).
Возможно concepts в delphi в Delphi.

Естествено C++ template для очень сильно усложнит и замедлит генерацию native кода, придется существенно расширить набор generic IL команд для всех операторов. + не будет никакой гарантии в полной безопасности этого кода. Поэтому generics + constraints очень удобное сочетание для .NET.

← →
Alkid © (2009-04-02 22:43) [66]

> oxffff © (02.04.09 22:33) [63]
> Приветствую тебя. :)

Я тоже тебя очень рад видеть :)

> Несмотря на то, что у меня есть и оба издания Рихтера по
> .NET, которые я прочитал и ECMA 335, ECMA 334, которые я
> тоже читал в рамках общего развития и читал также Expert
> .NET IL Assembler также оба.
> Я скажу честно, работа с С#, Nemerle и другими .NET языками
> меня пока обошли стороной.
> IL Asm и IL Dasm смотрел. Интересно.

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

← →
Alkid © (2009-04-02 22:45) [67]

> oxffff © (02.04.09 22:42) [65]
> Естествено C++ template для очень сильно усложнит и замедлит
> генерацию native кода, придется существенно расширить набор
> generic IL команд для всех операторов. + не будет никакой
> гарантии в полной безопасности этого кода. Поэтому generics
> + constraints очень удобное сочетание для .NET.

Обоснуй. C++ template раскрывается еще на этапе компиляции, причем не JIT. Почему там должен получаться небезопасный код?

← →
oxffff © (2009-04-02 22:48) [68]

> По идее в них должны были проявиться описанные тобой проблемы,
> но нет - все работает замечательно.

Можешь проверить?
Честно у меня больше уйдет на синтаксис на С# чем на сам алгоритм.
5000 пар объктов. Один из которых master - содержит делегат на другой. И прибить все root ссылки на slave объекты.

← →
oxffff © (2009-04-02 23:03) [69]

> Alkid © (02.04.09 22:45) [67]
>
> > oxffff © (02.04.09 22:42) [65]
> > Естествено C++ template для очень сильно усложнит и замедлит
>
> > генерацию native кода, придется существенно расширить
> набор
> > generic IL команд для всех операторов. + не будет никакой
>
> > гарантии в полной безопасности этого кода. Поэтому generics
>
> > + constraints очень удобное сочетание для .NET.
>
> Обоснуй. C++ template раскрывается еще на этапе компиляции,
> причем не JIT. Почему там должен получаться небезопасный
> код?

Почему С++ template нет в .NET?
Потому что это очень сильно бы усложнило бы IL набор и саму форму генерации кода.
В .NET assign IL команда является обобщенной(Не нужно указывать тип явно). Однако при генерации IL кода ты не можешь присвоить тип A типу Б, если они не совместимы. Но для этого они придумали хитрый трюк. Зачем делать небезопасный код. Давай классифируемым типы по контрактам(constraints). И сделаем проверку в run time минимальной.

Если бы такой код был допустим (а эта проверка осуществлялась run time), то нельзя гарантировать того, типы совместимы, поэтому такой код был бы в их терминологии Unverifible и не было гарантии того, что что типы совместимы, а если нет то нужно было отрыть по reflection impilict или explicit метод в run time. А это накладно.
В противном случае выдать ошибку.
Для операторов для унарных и бинарных операторов нужно было тоже делать generic IL иснструкции(которые сейчас такими не являются), и также при инстанцировании делать ковыряние reflection на наличие перегруженного метода для этих операторов и не дай бог там еще будет неоднозначный выбор. В их терминологии такой код не является верифицируемым. И сильно усложнил был транслятор IL кода в native.

← →
AndreyV © (2009-04-02 23:08) [70]

> [58] blackman © (02.04.09 21:55)
> AndreyV © (02.04.09 21:35) [57]
> Апрель наступил и это есть хорошо!
> Песня Булата Окуджавы такая есть
> Мама, мама, это я дежурный. Я дежурный по апрелю
> http://articles.org.ru/cn/showdetail.php?cid=5553
> Это лучше чем спор о будущем :)

Апрель - хорошо, и песня хорошая, и завтра обещают +10 и ясно, и ещё - весна не оффтопик!:)

← →
Городской Шаман (2009-04-02 23:11) [71]

> @!!ex © (02.04.09 21:27) [56]

Ну почему, последняя реализация WxWidgets, та которая 2-я. Отлично реализовали динамическую линковку событий. Там конечно сделано через шаманство с шаблонами, но работает, причем чистый С++ (но очень не советую пытаться понять как это работает, такого изврата даже на говнокоде не найдёшь).

← →
oxffff © (2009-04-02 23:17) [72]

> oxffff © (02.04.09 23:03) [69]

То есть если ты такое было возможно

ClassA<TypeA,TypeB>
....
TypeA a;
TypeB b;

a=a+b;

Первое встретили бы а и b, блин нет же виртульных методов (по типу equals)да и быть не может для оператора ADD. Лезем в reflection смотрим сигнатуру метода оператора add в типе TypeA с параметром TypeB и возвращаемым значением TypeA. Нету. Ищем с произвольным возращаемым значением. Нашли. Но с возращаемым значением типа TypeC.
Теперь ищем impilicit оператор для TypeC в преобразованием в TypeA.
Не нашли. Сообщили об ошибке в run time. Код небезопасный. Прервали работу поскольку ошибка инстанцирования параметризованного класса.
Некоторые компиляторы вроде сами генерируют код класса, если встречают инстаницрование generic класса в compile time. Некоторые такого не делают, а предоставляют .net сделать за них в run time.

← →
oxffff © (2009-04-02 23:20) [73]

> Некоторые компиляторы вроде сами генерируют код класса,

Вообще то IL код то будет у них идентичен. :)
Точнее в сборку добавляют описание класса.

← →
Игорь Шевченко © (2009-04-02 23:37) [74]

Городской Шаман (02.04.09 20:54) [52]

> Ну например в C++ нет делегатов(замыканий) на уровне языка
> (есть сторонний плагин на templat-ах). И вы видели как спроектирована
> MFC с её картой сообщений и прочими извратами? Самый яркий
> пример.

А причем тут "архитектура приложений" ? Какое отношение имеет реализация конкретных механизмов к архитектуре ?
Один и тот же проект был написан на С и на С++ (ну так вышло), в С нет виртуальных методов, они были успешно эмулированы на С, как таблицы указателей на функции (примерно также, как карты сообщений в MFC, механизмы достаточно похожи).
Но архитектура приложения осталась без изменений.

Ты вообще хоть какое-то разумное объяснение своим словам про архитектуру можешь дать или с тобой просто бесполезно разговаривать на серьезные темы и кроме ламерского флейма от тебя ничего не добиться ?

← →
Игорь Шевченко © (2009-04-02 23:40) [75]

Kostafey © (02.04.09 21:25) [54]

Это не философия, это детали реализации.

Пратта читать. Наизусть, до полного и окончательного просветления. Книжку звать "Языки программирования, разработки и реализация". Хоть она и древняя, но довольно фундаментальная и полезная для понимания отличий в философиях языков.

Вот у prolog (Lisp, APL) и у Delphi (C, C++, Java) действительно разная философия...

← →
Leonid Troyanovsky © (2009-04-03 00:08) [76]

> Alkid © (02.04.09 22:13) [59]

> Во-первых, обоснуй.

От обоснуя слышу ;)

--
Regards, LVT.

← →
Городской Шаман (2009-04-03 00:22) [77]

Удалено модератором

← →
oxffff © (2009-04-03 00:49) [78]

> Игорь Шевченко

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

Да и может не стоить путать философию языка программирования с парадигмой программирования.
Почитайте на досуге wiki парадигма программирования.

P.S. Попахивает беспределом на форуме.

← →
oxffff © (2009-04-03 00:56) [79]

> Поскольку в при полной эмуляции

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

← →
Игорь Шевченко © (2009-04-03 02:13) [80]

oxffff © (03.04.09 00:49) [78]

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

Осталась... Ты Фаулера на досуге почитай, про архитектуру приложений. Потому продолжим нашу увлекательную дискуссию.

Реймонда еще можешь почитать, который Эрик.

А у меня, извини, бисерный заводик закрылся.

← →
Riply © (2009-04-03 06:12) [81]

> [80] Игорь Шевченко © (03.04.09 02:13)
> А у меня, извини, бисерный заводик закрылся.

Я вижу кризис и Вас коснулся ? :)

← →
VirEx © (2009-04-03 09:48) [82]

паскаль, дельфи могут жить не только в компиляторах

а вобще будущее за прологом :-D

← →
palva © (2009-04-03 10:00) [83]

> паскаль, дельфи могут жить не только в компиляторах

а будут вечно жить в наших сердцах...

← →
test © (2009-04-03 10:35) [84]

palva © (03.04.09 10:00) [83]
А что Дельфи как бы все? А когда похороны были?

← →
Anatoly Podgoretsky © (2009-04-03 11:09) [85]

> test (03.04.2009 10:35:24) [84]

"будут" это будущее время, значит "Будущее Делфи" есть.
Кра товарищи"

← →
clickmaker © (2009-04-03 11:21) [86]

> Кра товарищи

Кроетратное кра

← →
oxffff © (2009-04-03 11:27) [87]

> Игорь Шевченко © (03.04.09 02:13) [80]

Если вы не можете отличить черное от белого, а так же строительные блоки одного языка от другого, а также филосию от парадигмы, то мне тратить на Вас время и вести с Вами дисскусию не интересно.
А уж тем более доказывать Вам что то бесполезно.

← →
test © (2009-04-03 11:30) [88]

oxffff © (03.04.09 11:27) [87]
Вот взял и расстроил всячески Игоря он теперь не сможет: спать, есть, программировать....
)))

← →
Alkid © (2009-04-03 11:43) [89]

> oxffff © (02.04.09 23:03) [69]
> Почему С++ template нет в .NET?

Твоя неправда :) В С++/CLI поддерживаются И template И generics.

> Alkid © (03.04.09 11:43) [89]
>
> > oxffff © (02.04.09 23:03) [69]
> > Почему С++ template нет в .NET?
>
> Твоя неправда :) В С++/CLI поддерживаются И template И generics.
>

Я продолжаю настаивать, что идеалогии template нет в .NET,

То что в управляемом С++ можно использовать template style, так это заслуга не .NET, поскольку.

Comparing Templates and Generics
Key differences between generics and C++ templates:

Generics are generic until the types are substituted for them at runtime. Templates are specialized at compile time so they are not still parameterized types at runtime

The common language runtime specifically supports generics in MSIL. Because the runtime knows about generics, specific types can be substituted for generic types when referencing an assembly containing a generic type. Templates, in contrast, resolve into ordinary types at compile time and the resulting types may not be specialized in other assemblies.

Generics specialized in two different assemblies with the same type arguments are the same type. Templates specialized in two different assemblies with the same type arguments are considered by the runtime to be different types.

Generics are generated as a single piece of executable code which is used for all reference type arguments (this is not true for value types, which have a unique implementation per value type). The JIT compiler knows about generics and is able to optimize the code for the reference or value types that are used as type arguments. Templates generate separate runtime code for each specialization.

> oxffff © (03.04.09 12:08) [91]
> Я продолжаю настаивать, что идеалогии template нет в .NET,

"Идеологии template" нет и в системе команд процессора x86 :), что не мешает C++ с успехом поддерживать шаблоны в нативном коде. Ты прав в том смысле, что шаблоны - это фитча языка, а не платформы, в то время, как дженерики - фитча платформы. Замечу, кстати, что в Java всё наоборот - дженерики там являются именно фитчей языка, а не платформы.

Моя позиция, собственно, заключается в том, что никто не мешает иметь в .NET шаблоны и что их наличие никак не влияет на безопасность кода. Наличие шаблонов в С++ - тому доказательство.

Вопрос о том, какой из инструментов является предпочтительным, лично для меня остаётся открытым. Основное, с моей точки зрения, различие дженериков (если обобщить их Java и .NET реализации) заключается в том, что они не реализуют duck typing для своих аргументов, в то время как шаблоны реализуют. Это ограничение делает невозможным ряд интересных техник программирования.

> Alkid © (03.04.09 12:40) [92]

Я практически полностью разделяю твое мнение, за исключением того, что

> Моя позиция, собственно, заключается в том, что никто не
> мешает иметь в .NET шаблоны и что их наличие никак не влияет
> на безопасность кода. Наличие шаблонов в С++ - тому доказательство.
>

В том и дело, что при передаче параметров через разные сборки нельзя
гарантировать корректную передачу типа и проверить идентичность типа параметра метода и типа переданного в run time.
Я бы выразился это как наличие cross typing и inner typing(возможно имеется другой термин). То есть в пределах одного исполняемого модуля проверить идентичность типов и гарантировать ее можно.
В пределах разных нельзя.
Нет возможности проверить, что к типу применялись тот же набор type constructors в той же последовательности. Поэтому получив параметр из вне ты можешь только надеятся, что он именно того типа. А в случае с generics у среды есть возможность это проверить в run time при генерации native кода вызова. Поэтому здесь полная верификация. IMHO.

Будущее Delphi не зависит от той или иной популярности пакетов по мере
количества байтов создаваемого файла, по мере скорости компилляции, по мере
(не) трудности создания исходников.

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

Delphi - это дружественный пакет, позволяющий сделать "программу".
А не выпендриваться от того, что "программа" сделана на С++.

Delphi, как ни назхови, хоть пакетом визуальных компонетов, хоть "языком",
оне (Delphi) не станут хуже.

Пройдёт много лет.
Байкеры состарят себя.
Их мотоциклетные угодья сгниют.
Их негламурныя подруги постареют.
Их "язык" станет нонсенсом.
Подростки перестанут понимать устаревший slang.

И выйдет новый мальчик, который захочет сделать простую программку.
Про крестики и нолики.
Ему не понравится "птичий язык" С.

Ему понравятся Delphi.
Потому, что там функцию можно назвать "Krestikinoliki".
И там, наверняка придумают новую компоненту с похожим названием.

Мальчик, восторженно всхлипывая, сбацает программку 7-го марта.
А восьмого гордо подарит своей девочке.

И девочка будет в восторге!

А негламурный байкер, движущий тонны на своём С++, на своём мотоцикле,
позавидует наивному пользователю Delphi.

> А негламурный байкер, движущий тонны

если тонны, то это уже негламурный дальнобойщик

> Копир © (03.04.09 20:10) [98]

Это не то.
Речь шла о том, как ты предлагаешь в run time компилятору быстро развернуть обобщенный код вида?

AddExpression<T,U>=class
class function Expression(const a:T;const b:U):T;static;
end;

class function AddExpression<T, U>.Expression(const a: T; const b: U): T;
begin
result:=a+b;
end;

>oxffff © (03.04.09 20:21) [100] :
>Это не то.

Сергей, ну чего Вы меня грузите?
Я ваще не программист.

Я так. Писатель :)

> Игорь Шевченко © (03.04.09 02:13) [80]

В книге Фаулера "Архитектура корпоративных программных приложений" 2006 г. ИСПРАВЛЕННОЕ ИЗДАНИЕ на стр. 28 (Введение) он лаконично уклоняется от дачи чёткого определения термина "архитектура"
Цитата:
"Одно из странных свойств, присущих индустрии программного обеспечения, связано с тем, что какой-либо термин может иметь множество противоречивых толкований. Вероятно, наиболее многострадальным оказалось понятие архитектура (architecture). Мне кажется, оно принадлежит к числу тех нарочито эффектных слов, которые употребляют
ся преимущественно для обозначения чего-то, считающегося значительным и серьезным."

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

И если

> Игорь Шевченко © (02.04.09 23:37) [74]

> Один и тот же проект был написан на С и на С++ (ну так вышло),
> в С нет виртуальных методов, они были успешно эмулированы
> на С, как таблицы указателей на функции (примерно также,
> как карты сообщений в MFC, механизмы достаточно похожи).
>

, то, это уже тянет на архитектурное решение, поскольку всё остальное уже завязывается на таблицы указателей на функции. И, насколько я понимаю, выбросив таблицы указателей на функции, получим распад всей системы в целом. Я не прав?

31512 © (03.04.09 20:44) [102]

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

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

> Игорь Шевченко © (03.04.09 21:09) [103]

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

31512 © (03.04.09 21:28) [104]

> Значит это не архитектурное решение.

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

Допустим еще один пример - одним из аспектов архитектуры приложения является работа с плагинами (опять же, по заранее оговоренному контракту).

Зависит ли архитектура от того, на каком языке написаны плагины ? (Ну скажем, плагины для работы с изображениями, всякие там эффекты...)

> Игорь Шевченко © (03.04.09 21:09) [103]
> В моем понимании - архитектура приложения - это совокупность
> частей и интерфейсов между ними (не механизмов реализации
> взаимодействия, в данном случае неважно, посылает ли одна
> часть другой оконное сообщение или вызывает другую часть,
> как метод объекта),

Уже появилось свое определение архитектуры.

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

Рассмотрим любую произвольную архитектуру. Это по вашему определению набор частей и интрерфейсов между ними. Вы намеренно отказываетесь от деталей реализации. Тогда рассматривая произвольную часть архитектуры можно ее также рассмотреть как части 2 уровня и интрерфейсы между ними.
Рекурсивно спускаясь + обобщая на все архитектуры можно заключить следующее - все архитектуры идентичны. поскольку все состоит из частей и интерфейсов между ними. А это извините бред.

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

Здесь смешалось все кони, люди.

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

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

> Игорь Шевченко © (03.04.09 21:49) [105]

> Зависит ли архитектура от того, на каком языке написаны плагины ?

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

> 31512 © (03.04.09 22:16) [108]

Язык здесь не причем. Тебе пытаются подменить понятия.
Любой плагин так или иначе завязан на конкретной архитектуре, то есть нельзя плагины одной системы вставить в другую без соблюдения правил - конракт(не забывает, что контракт это обобщенное решение, но не архитектура, а ее часть). То есть любой плагин завязан на конкретной архитектуре.
Даже при условии создании обобщего решения универсального плагина - у а него будет своя архитектура, можно создать другой обобщего решения универсального плагина(со своей архитектурой) , которое будет не совместимо с первым. Я надеюсь ты понял мою мысль.

Плагины одной архитектуры (одной библиотеки) не будут подходить для другой архитектуры(другой библиотеке). Поскольку обязаны поддерживать детали(кот)

to 31512

> oxffff © (03.04.09 22:31) [109]
> контракт это обобщенное решение,

Далее если рассмотреть само понятие контракта можно рассмотреть как обязанность одного перед другим. Однако технически сам контракт(строительный элемент) как тип является строительным блоком. В одном яыке это может быть интерфейсы, в другом классы, в третьем вызовы через оператора телефона со своим контрактом, .... . И хотя все это будет контракты мы не будем забывать что каждый из них обладает своим индивидуальным устройством не совместимым с другим.
И eсли есть узлы А и B, которые связаны контрактом C.
То в одной библиотеке сам контракт это COM интерфейс, а в другом это dynamic method. И хотя это все конракты, архитектурно они различны. А значит и библиотеки архитектурно различны, но обладают сходным решением. Надеюсь теперь ты понял меня.

31512 © (03.04.09 22:16) [108]

> Думаю, нет, не зависит. Главное, чтобы они были написаны
> по правилам для таких плагинов.

Я к тому же. Тот же Фаулер, те же Гамма, Влисидис и сотоварищи, демонстрируя аржитектурные решения не привязывают их к какому-то конкретному языку, а то, что приводят примеры на С++ или Smalltalk (или на C# и Java у Фаулера) - ну надо же на чем-то приводить приводить примеры, чтобы пояснить мысль. Безусловно, часть каких-то решений (из тех же паттернов банды четырех) уже может быть встроена в какой-то конкретный язык, но архитектура от этого не меняется. Просто используются встроенный средства для тех или иных архитектурных решений.

Собственно весь спор начался с утверждения [41], что архитектура прогибается под возможности языка, если что :)

> oxffff © (03.04.09 22:31) [109]

Поскольку пост в мой адрес - отвечу.

> Язык здесь не причем. Тебе пытаются подменить понятия.

Никто, мне ничего подменить не пытается. Мысль я твою понял.
Есть система А. Она ожидает, что в каждом плагине будет экспортирована функция
function Attach: TAttachResult;stdcall;
TAttachResult - определён архитектурой.
Понятно, что не получив эту функцию, система отвергнет плагин, равно и в том случае, если TAttachResult не будет соответсвовать соглашению.
Просто ты хочешь сказать, что содержание TAttachResult и есть детализация, которой пренебрегать нельзя. Так? Если так, то это никак не нарушает определения в [103].

> Игорь Шевченко © (03.04.09 22:44) [111]

> Собственно весь спор начался с утверждения [41], что архитектура
> прогибается под возможности языка, если что :)

Иногда "архитектурят" с учётом возможностей языка. По мне, так, тут бяка может случиться.

Еще одно определение (длинное слегка, приходится ужимать, надеюсь, без потери деталей):

"Архитектура должна определять основные компоненты программы. Каждый компонент является классом или набором классов классов/методов, которые в совокупности реализуют высокоуровневые функции программы, такие как взаимодействие с пользователем, отображение WEB-страниц, инкапсуляция бизнес-правил или доступ к данным.
Архитектура должна четко определять ответственность каждого компонента. Компонент должен иметь одну область ответственности и как можно меньше знать об областях ответственности других компонентов. Архитектура должна определять правила коммуникации для каждого компонента. Она должна описывать, какие другие компоненты данный компонент может использовать непосредственно, какие косвенно, а какие вообще не должен использовать.
Аритектура должна описывать основные классы приложения, иерархии классов, а также изменения состояний и время существования объектов.
Если система достаточно велика, архитектура должна описывать организацию классов в подсистемы."

...
Ну и еще на пару страниц

(с) Стив МакКоннел, "Совершенный код"

> 31512 © (03.04.09 22:49) [112]

Я хочу сказать что есть решение, и есть архитектура этого решения.
Решение может быть общим, но у него будет все равно конкретная архитектура.

Что касаемо системы А. Она ожидает экспортированную функцию С.
А теперь представь систему B, которая тоже ожидает экспортированную функцию С. НО!

в систему A она передается передачей адреса stdcall функции.
а в систему B она передается с помощью объекта с динамическим методом.
И там и там есть контракт С, но реализован он по разному.
Решения сходны, но архитектурно различны, поскольку архитектуры не совместимы(нельзя передать С из решения B, в решение A).
То есть возможости средства реализации накладывают отпечаток на архитектурное решение. И коли тут уже упомянули GOF, то фабрика класса С++ и использование метакласса в Delphi следуют одной и той же цели - динамическому созданию объекта.
Это два сходных решения, но архитектурно различных.

> Игорь Шевченко © (03.04.09 23:00) [114]

МакКоннела не читал. Только разобрался с тензорами инерции и сил трения, своей модели атм. аэрозоля. Теперь нахожусь в состоянии исследования зависимости сечения поглощения от длины волны и уравнения теплового баланса. Вот чувствую, что придётся после защиты диссертации, читать и МакКоннела, и Реймонда, и Э. Гамма Р. Хелма Р. Джонсона Дж. Влиссидеса
Так что я нахожусь в базисном состоянии Винни-Пуха:
"Ты не забывай, что у меня в голове опилки. Длинные слова меня только расстаивают..." .
:-)

← →
kaif (2009-04-04 00:57) [118]

← →
Городской Шаман (2009-04-04 01:20) [119]

Это фигня. Вот здесь .ПТУшники с Джавистами схлеснулись по поводу виртуальных методов.
http://www.developers.org.ua/forum/topic/463/page/2#post-4853

Оказывается, виртуальные методы есть зло?

> Городской Шаман (04.04.09 01:20) [119

Как это фигня? То есть ты хочешь сказать, что такого нет?

← →
Городской Шаман (2009-04-04 02:12) [121]

> oxffff © (04.04.09 01:21) [120]
>
> > Городской Шаман (04.04.09 01:20) [119
>
> Как это фигня? То есть ты хочешь сказать, что такого нет?

Фигня ваш холивор. Вот на украинских формах холиворы и по 1000 постов бывают, например даже не о языке, а о тех же виртуальных методах.

> Городской Шаман (04.04.09 02:12) [121]

Нет фоливара. Есть обмен мнениями. Я честно как только увидел вопрос для чего нужны виртуальные методы, сразу представил о чем может идти речь.
Мне это не интересно.
Далее ткнул наугад страницу то ли 4 то ли 5. Увидел только два умных и знакомых слова callvirt(интсрукция MSIL) и

ковариантность. Это

Covariance and contravariance provide a degree of flexibility when matching method signatures with delegate types. Covariance permits a method to have a more derived return type than what is defined in the delegate. Contravariance permits a method with parameter types that are less derived than in the delegate type.

Example 1 (Covariance)
This example demonstrates how delegates can be used with methods that have return types that are derived from the return type in the delegate signature. The data type returned by SecondHandler is of type Dogs, which derives from the Mammals type that is defined in the delegate.

C# Copy Code
class Mammals
{
}

class Dogs : Mammals
{
}

class Program
{
// Define the delegate.
public delegate Mammals HandlerMethod();

public static Mammals FirstHandler()
{
return null;
}

public static Dogs SecondHandler()
{
return null;
}

static void Main()
{
HandlerMethod handler1 = FirstHandler;

// Covariance allows this delegate.
HandlerMethod handler2 = SecondHandler;
}
}

Example 2 (Contravariance)
This example demonstrates how delegates can be used with methods that have parameters of a type that are base types of the delegate signature parameter type. With contravariance, you can now use one event handler in places where, previously, you would have had to use separate handlers. For example, you can now create an event handler that accepts an EventArgs input parameter and use it with the Button.MouseClick event that sends a MouseEventArgs type as a parameter, and also with TextBox.KeyDown event that sends a KeyEventArgs parameter.

C# Copy Code
System.DateTime lastActivity;
public Form1()
{
InitializeComponent();

lastActivity = new System.DateTime();
this.textBox1.KeyDown += this.MultiHandler; //works with KeyEventArgs
this.button1.MouseClick += this.MultiHandler; //works with MouseEventArgs

}

// Event hander for any event with an EventArgs or
// derived class in the second parameter
private void MultiHandler(object sender, System.EventArgs e)
{
lastActivity = System.DateTime.Now;
}
.

> Городской Шаман (04.04.09 02:12) [121]

Ты там наблюдай за ними. Как только увидишь затык, приглашай сюда.
Все расскажем и покажем. Как? Что? Куда? Почему?

← →
iZEN (2009-04-04 17:47) [124]

> Kostafey © (02.04.09 17:37) [37]
>
> > [35] test © (02.04.09 17:29)
>
> Судя по тому что написано в википедии,
> Ruby создавался как мегасовременный и
> продуманный язык, который учел все достоинства
> и недостатки предыдущих. Посему в какой-то
> момент загорелся идеей изучить, тем более, что
> есть реализация на java.
> А Ruby on rails - опять-таки мегасовременный
> фреймворк для веба, где, мол все уже есть.

В FreeBSD на Ruby написан инструмент сопровождения программного обеспечения "portupgrade". Больше никаких тулзовин на нём не встречал (не было нужды).

Пик популярности Ruby и RoR пришёлся на 2005-2006гг. Сейчас оно как-то заглохло и работает только в своей нише. Да ещё JRuby сделали для переноса Ruby-библиотек на Java (см NetBeans 6.5.x). Хотя там оно ненужно со всей очевидностью, так как есть фреймворки JSP/JSF и разнообразие чётко специфицированных библиотек JEE.

На Unix-подобных операционках наиболее популярны такие языки как C (системный код), Perl (в основном автоматизированные инструменты сборки других программ), Python (связующее звено между приложениями), другие скриптовые языки (Bash в Linux; sh/tcsh в FreeBSD), включая "экзотический" Lua и препроцессор M4.

Для программирования в Web под Unix применяются PHP (стэк LAMP) и Java (JSP/JSF/JEE). Серьёзное прикладное программирование невозможно без интегрированных сред типа NetBeans и Eclipse (обе поддерживают много языков программирования и разметки, а также интеграцию разнородных проектов и сопровождение кода).

DVCS представлены широким спектром бесплатных и проверенных временем систем контроля версий. От стремительно устаревающей CVS и "переходной" SVN до современных Git и Mercurial.

Учитывая преобладающий сете-центричный характер разработок, в которых разработчики ни разу в жизни не видели друг друга, изобретаются новые способы сопровождения как исходного кода (DVCS), так и готового к распространению, включая необходимые библиотеки и инструменты для повторяемой сборки и управления жизненным циклом ПО (синхронизированные репозитории — см. Apache Maven2 для Java, например).

> [124] iZEN (04.04.09 17:47)

Спасибо за обзор.

Кстати, о Python. Один из Mercurial-клиентов как раз на нем
писан (PyGTK). Хотя, это похоже, скорее экзотика.

> Kostafey © (04.04.09 20:23) [125]
> Кстати, о Python. Один из Mercurial-клиентов как раз на
> нем
> писан (PyGTK). Хотя, это похоже, скорее экзотика.

Да. Команда разработчиков Python совсем недавно выбрала Mercurial в качестве основной DVCS проекта. Git им не понравился, потому что написан на C. :))

На Python написан популярный torrent-клиент Deluge. И ещё куча полезных оконных приложений.

Будущее Делфи? Найти похожие ветки