IsDelphiDead.com

← →
ZeroDivide © (2009-10-27 13:42) [0]

Сабж

← →
Кто б сомневался © (2009-10-27 13:45) [1]

Набрал
IsC++dead.com - не нашло. Но ведь это правда, в отличии от Delphi.

← →
Alkid © (2009-10-27 14:28) [2]

> Кто б сомневался © (27.10.09 13:45) [1]

Т.е. ты хочешь сказать, что С++ мертвее Дельфи?
Похоливарим?
;)

← →
Кто б сомневался © (2009-10-27 15:28) [3]

> Т.е. ты хочешь сказать, что С++ мертвее Дельфи?

Конечно товарищ. Ведь в планах MS уже давно C#. Майкрософт угрохала дофига денег на С# и всячески его продвигает.
Конечно для определенного сегмента он останется, как asm, но в большинстве будет C#, уже давно это есть.
C# рулит.

← →
Кто б сомневался © (2009-10-27 15:28) [4]

> но в большинстве будет C#, уже давно это есть.

Т.е. уже сейчас это есть, причем давно.

← →
Игорь Шевченко © (2009-10-27 15:50) [5]

> Майкрософт угрохала дофига денег на С# и всячески его продвигает

И че ? Весь мир бросается писать на то, что продвигает MS ?
Вот уж вряд ли...

← →
Anatoly Podgoretsky © (2009-10-27 16:05) [6]

> Игорь Шевченко (27.10.2009 15:50:05) [5]

На платформе Виндоус это вопрос времени, например резкое снижение примеров в MSDN на C++ уже наблюдается, пока они еще изредка бывают, но новых почти нет. Кроме C++ убивают и J++, остается VB.NET и C#.
Но Микрософт не постоянен.

← →
DrPass © (2009-10-27 16:21) [7]

> И че ? Весь мир бросается писать на то, что продвигает MS
> ?
> Вот уж вряд ли...

Не весь, где-то около половины

← →
Игорь Шевченко © (2009-10-27 17:28) [8]

Anatoly Podgoretsky © (27.10.09 16:05) [6]

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

DrPass © (27.10.09 16:21) [7]

> Не весь, где-то около половины

Около половины как писали на С, так и будут продолжать

← →
GDI+ (2009-10-27 18:26) [9]

> Кто б сомневался © (27.10.09 15:28) [3]

C# без С++ платформа для студенческих поделок. Чейчас всё ресурсоёмкое пишут на С++ и линкуют в качестве dll к проектам на C#. А на C# окошечки.

← →
GDI+ (2009-10-27 18:32) [10]

> Anatoly Podgoretsky © (27.10.09 16:05) [6]
>
> > Игорь Шевченко (27.10.2009 15:50:05) [5]
>
> На платформе Виндоус это вопрос времени, например резкое
> снижение примеров в MSDN на C++ уже наблюдается, пока они
> еще изредка бывают, но новых почти нет. Кроме C++ убивают
> и J++, остается VB.NET и C#.
> Но Микрософт не постоянен.

Вы не поверите но этого тоже нет в MSDN и никогда не было, но между тем это используют. И тех кто использует называют kernel guru.

http://undocumented.ntinternals.net/

← →
Rouse_ © (2009-10-27 18:49) [11]

Мошт уже хватит пионерщину сюда выкладывать? Если у человека руки из (не оттуда) рустут, в чем Дельфи то виноват?
Мне вот вообще асм нравиться, что абсолютно не мешает кодить как на тех-же сях, так и пресловутой дельфи вкупе со скриптоподобными поделками.

← →
Eraser © (2009-10-27 19:24) [12]

> [3] Кто б сомневался © (27.10.09 15:28)

> Конечно товарищ. Ведь в планах MS уже давно C#. Майкрософт
> угрохала дофига денег на С# и всячески его продвигает.

интересно, когда клиенты у тебя начнут просить решение под Mac OS X, на чем писать будешь? )
есть java, есть php, есть все остальное.

← →
Eraser © (2009-10-27 19:27) [13]

> [9] GDI+ (27.10.09 18:26)

> C# без С++ платформа для студенческих поделок.

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

← →
Anatoly Podgoretsky © (2009-10-27 19:37) [14]

> Eraser (27.10.2009 19:24:12) [12]

А на чем там пока пишут? Вот на том и писать. Ведь проблема будет не с языком, а с АПИ и системой.

← →
Eraser © (2009-10-27 19:44) [15]

> [14] Anatoly Podgoretsky © (27.10.09 19:37)

обычно клиентское (прикладное) приложение стоит писать на джаве, причем оно одинаково будет работать и в windows и в mac и в никсах. системные приложения стоит писать именно на том, на чем обычно пишут под конкретную ОС.

← →
Игорь Шевченко © (2009-10-27 19:52) [16]

> обычно клиентское (прикладное) приложение стоит писать на
> джаве, причем оно одинаково будет работать и в windows и
> в mac и в никсах

Только его работа mac и *nix чаще всего нафиг никому не нужна

← →
Eraser © (2009-10-27 19:58) [17]

> [16] Игорь Шевченко © (27.10.09 19:52)

насчет *nix соглашусь, насчет mac - категорически не соглашусь. какой-то специализированный софт, о котором я написал в [13], ясное дело, будут запускать только на работе и только из винды. а вот на либой ширпотребный софт, либо специализированное клиентское ПО спрос на версии под Mac сильно не дооценивают.

← →
Rouse_ © (2009-10-27 20:40) [18]

> Eraser © (27.10.09 19:24) [12]
> интересно, когда клиенты у тебя начнут просить решение под
> Mac OS X, на чем писать будешь? )

ИМХО не только клиент должен выбирать работника(контору), но и работник (контора) должна смотреть на клиента :)
От нас тоже сейчас ждут решения под линупсь - отметаем :)

← →
Плохиш © (2009-10-27 20:44) [19]

> Rouse_ © (27.10.09 20:40) [18]

> От нас тоже сейчас ждут решения под линупсь - отметаем :
> )

А могли бы к стоимости пару нулей справа добавить ;-)

← →
Игорь Шевченко © (2009-10-27 20:45) [20]

> а вот на либой ширпотребный софт, либо специализированное
> клиентское ПО спрос на версии под Mac сильно не дооценивают.
>

А примеры приложений с недооцененным спросом под Мак можно привести ?

← →
Alkid © (2009-10-27 21:37) [21]

> Кто б сомневался © (27.10.09 15:28) [3]
> Конечно товарищ. Ведь в планах MS уже давно C#. Майкрософт
> угрохала дофига денег на С# и всячески его продвигает.

Кроме Microsoft Visual C++ и Windows есть куча других инстументариев для С++ и операционных систем. Конечно, нельзя отрицать, что C# вытесняет плюсы из многих областей (чему я, в целом, рад), но он так же вытесняет оттуда и Дельфи :)

И вообще вопрос был не "C++ vs C#", а "C++ vs. Deplhi".

← →
Кто б сомневался © (2009-10-27 21:42) [22]

Факт остается фактом. Корпорация MS правит балом, рынок ее огромен влияние также. MS говорит о своих планах. А в планах у нее C#.
Так что затухание хорошего языка заметно невооруженным глазом. C# не нативный язык да, что влияет на скорость работы программы, в итоге лет через 10 из нативных поддерживаемых и развиваемых останется язык Delphi, если новый не прийдет.. имхо.
C++ будут юзать конечно, но весь вопрос в поддержке и развитии его и адаптации к следующей волне ОС Win.

← →
Игорь Шевченко © (2009-10-27 22:17) [23]

> Корпорация MS правит балом, рынок ее огромен влияние также

Ты выдаешь желаемое за действительное

← →
Кто б сомневался © (2009-10-27 22:28) [24]

> Ты выдаешь желаемое за действительное

1, Перефразруем твои слова - т.е. MS не правит балом, рынок ее мизерный, и влияние также слабенькое. Чето нето, верно?.

2,Кто занимается основной поддержкой и развитием этого языка?

← →
Alkid © (2009-10-27 22:48) [25]

> Кто б сомневался © (27.10.09 21:42) [22]

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

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

Вообщем, сплошная диалектика :)

← →
Alkid © (2009-10-27 22:48) [26]

> Кто б сомневался © (27.10.09 22:28) [24]
> 2,Кто занимается основной поддержкой и развитием этого языка?

Комитет по стандартизации.

← →
Суслик_ (2009-10-27 23:03) [27]

http://isdelphidead.com/API/?json

← →
Кто б сомневался © (2009-10-27 23:14) [28]

> Alkid © (27.10.09 22:48) [26]

А комитет из кого состоит?

← →
Кто б сомневался © (2009-10-27 23:39) [29]

> Комитет по стандартизации.

Короче, основным развитием С++ занимается MS, а не комитет. Комитет корректирует только направление.

← →
Kostafey © (2009-10-27 23:41) [30]

> [22] Кто б сомневался © (27.10.09 21:42)
> в итоге лет через 10 из нативных поддерживаемых и развиваемых
> останется язык Delphi, если новый не прийдет.. имхо.

А он с 8-й версии разьве не под .net компилит?
(Это не прикол, я правда не в курсе т.к., на 7-й
остановился).

М все же. По-моему для java нет контраргументов в плане
конкуренции C#. Сейчас производительность swing хорошая.
Фанатам предложены интерморды для GTK.
Для хакеров (в хорошем смысле) есть tuProlog, Clojure.

← →
Кто б сомневался © (2009-10-27 23:58) [31]

> А он с 8-й версии разьве не под .net компилит?

Это восьмая была сугубо под нет. После они выделили его в отдельный продукт Delphi Prism - который развивается отдельно. Сам делфи (2005-2010) нативный и продолжит оставатся им.

← →
Rouse_ © (2009-10-27 23:59) [32]

> Плохиш © (27.10.09 20:44) [19]
> А могли бы к стоимости пару нулей справа добавить ;-)

Так в том-то и дело, именно это и сделали.
После чего клиент сделал удивленно-огромно-обиженные глаза и сказал сакраментальную фразу: "Это как-же так получается, товарищи, ведь линукс бесплатен" :)

← →
Плохиш © (2009-10-28 00:21) [33]

> Rouse_ © (27.10.09 23:59) [32]

Я задаю сразу встречный вопрос про стоимость обслуживания :-)

← →
wicked © (2009-10-28 00:31) [34]

> Кто б сомневался © (27.10.09 23:39) [29]

> > Комитет по стандартизации.
> Короче, основным развитием С++ занимается MS, а не комитет.
> Комитет корректирует только направление.

ты очень сильно ошибаешься
ну или троллишь

← →
Дмитрий Белькевич (2009-10-28 00:32) [35]

Думали, что умрёт Delphi, а MS плюсы списала... Абыдна.
Нет, плюсы, конечно, не умрут. И писать на них будут. Только всё меньше для Wintel.

← →
Суслик_ (2009-10-28 00:39) [36]

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

Очень многие пишут для себя:
а) Для своего ИТ
б) Для своих программ, которые продают.

В смысле работать на себя Дельфи незаменим.

← →
Плохиш © (2009-10-28 00:46) [37]

> незаменим.

Все незаменимые лежат на кладбище...

← →
Суслик_ (2009-10-28 00:49) [38]

> Плохиш © (28.10.09 00:46) [37]
>
>
> > незаменим.
>
> Все незаменимые лежат на кладбище...

а вот я еще более информативное сообщение скажу - Плохиш объелся варенья и "сдал" Кибальчиша!

Ну это сарказм по манере общения здесь.

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

← →
Дмитрий Белькевич (2009-10-28 00:55) [39]

>В смысле работать на себя Дельфи незаменим.

Конечно. Когда работаешь на себя любимого то Delphi - идеальная среда.

← →
Дмитрий Белькевич (2009-10-28 01:04) [40]

> Все незаменимые лежат на кладбище...

Жалко только, что заменёнными оказались плюсы. А что же Delphi? Delphi Everywhere ;)

← →
Германн © (2009-10-28 01:09) [41]

> Rouse_ © (27.10.09 23:59) [32]
>
>
> > Плохиш © (27.10.09 20:44) [19]
> > А могли бы к стоимости пару нулей справа добавить ;-)
>
> Так в том-то и дело, именно это и сделали.
> После чего клиент сделал удивленно-огромно-обиженные глаза
> и сказал сакраментальную фразу: "Это как-же так получается,
> товарищи, ведь линукс бесплатен" :)
>

!!!
:)
Меня тоже когда-то давно спрашивали про версию для линукс. И это для ПО, которое не обновлялось (кроме исправления багов) с 98-го года.

← →
Кто б сомневался © (2009-10-28 01:20) [42]

> wicked © (28.10.09 00:31) [34]
>
> > Кто б сомневался © (27.10.09 23:39) [29]
>
> > > Комитет по стандартизации.
> > Короче, основным развитием С++ занимается MS, а не комитет.
>
> > Комитет корректирует только направление.
>
> ты очень сильно ошибаешься
> ну или троллишь

Так скажи как правильно. чего ж не сказал?

← →
Германн © (2009-10-28 01:23) [43]

> Суслик_ (28.10.09 00:39) [36]
>
> братцы, не все же пишут, что называется на заказ. не все
> же надо писать на технологиях, которые "навсегда" и в "любое"
> время клиент, сможет найти заказчиков.
>
> Очень многие пишут для себя:
> а) Для своего ИТ
> б) Для своих программ, которые продают.
>
> В смысле работать на себя Дельфи незаменим.

+1

← →
TIF © (2009-10-28 01:45) [44]

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

PS: Хм. Оказывается к развитию C# и Delphi руку один и тот же человек. Вот как оно в жизни бывает...

← →
Eraser © (2009-10-28 01:47) [45]

> [20] Игорь Шевченко © (27.10.09 20:45)

во-первых, большинство уже известных продуктов имеют версии под Mac (skype, продукты adobe, ms office, google earth, vnc), хотя многие из них так и не имеют версии под *nix.
разработчиков же тех продуктов, которые не имеют таких версий (qip, Google Chrome - разработка под уже мак начата, AutoCad, 3d max, радмин) постоянно атакуют макофилы, с просьбой сделать наконец версию под мак.

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

> От нас тоже сейчас ждут решения под линупсь - отметаем :
> )

а писали бы на джаве, уже бы продали без лишних разговоров ;-)

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

Eraser © (28.10.09 01:47) [45]

И продукты adobe и ms office имеют версии под Мак с незапамятных времен. Для справки.

Я ни разу не слышал о просьбах сделать версии под мак наших программ. Под линукс было дело, просили. Не сделали.

← →
Eraser © (2009-10-28 03:44) [47]

> [45] Eraser © (28.10.09 01:47)

> И продукты adobe и ms office имеют версии под Мак с незапамятных
> времен. Для справки.

> во-первых, большинство уже известных продуктов имеют версии
> под Mac (skype, продукты adobe, ms office, google earth,
> vnc), хотя многие из них так и не имеют версии под *nix.

> Я ни разу не слышал о просьбах сделать версии под мак наших
> программ.

видимо такая специфика.

← →
GDI+ (2009-10-28 03:58) [48]

> Alkid © (27.10.09 22:48) [25]
>
> Другое дело, что С++ устарел и комитет сильно тормозит его
> развитие.

И слава Богу, что тормозит. C# как был скриптомордием, так и останется. А С++ универсален. Кроме того С# изучить можно за два месяца и далее остановится в развитии, то С++ можно изучать и 15 лет каждый раз узнавая что-то новое.

Поэтому во время кризиса первыми вылетели с работы PHP-шники и C#, так как их набрать из "школьников" в любой момент можно или обучить за 1-2 месяца. А С++ специалиста нужно обучать несколько лет, это "золотой фонд".

← →
GDI+ (2009-10-28 04:02) [49]

> Дмитрий Белькевич (28.10.09 01:04) [40]
> Жалко только, что заменёнными оказались плюсы.

Не плюсы, а MFC и прочее от MS. А вот тот же wxWidgets и QT с C++ активно используется.

← →
Alkid © (2009-10-28 09:18) [50]

> Кто б сомневался © (27.10.09 23:14) [28]
> > Alkid © (27.10.09 22:48) [26]
> А комитет из кого состоит?

Новый стандарт С++ (неофициальное название C++0x) разрабатывает комитет под названием "ISO/IEC JTC1/SC22/WG21 C++ Standards Committee" Он состоит из разных людей. Майкрософт имеет там свое представительство в подкомитетах, но не более того.

> Короче, основным развитием С++ занимается MS, а не комитет.
> Комитет корректирует только направление.

Это заблуждение. Интересно, на основании чего оно возникло?

Очень советую книгу "Дизайн и эволюция С++" за авторством Страуструпа. Там, в частности, есть и описание того, каким образом идет процесс разработки и стандартизации С++.

> Дмитрий Белькевич (28.10.09 01:04) [40]
> Жалко только, что заменёнными оказались плюсы.

Не более, чем Дельфи :)

> TIF © (28.10.09 01:45) [44]
> PS: Хм. Оказывается к развитию C# и Delphi руку один и тот
> же человек. Вот как оно в жизни бывает...

И это, кстати, очень заметно по первой версии С#.

← →
Alkid © (2009-10-28 09:36) [51]

> GDI+ (28.10.09 03:58) [48]
> И слава Богу, что тормозит. C# как был скриптомордием, так и останется.

Аргументируй, что ли. А то мы тут на C# продукт пишем, а "мужики-то не знают!".

> Кроме того С# изучить можно за два месяца и далее остановится
> в развитии, то С++ можно изучать и 15 лет каждый раз узнавая
> что-то новое.

Абсолютное заблуждение.
C# развивается гораздо более динамично, чем C++, новые возможности в нем добавляются быстрее и, я бы сказал "смелее". Причем в С# происходят не просто косметические улучшения, а наблюдается конкретный сдвиг парадигмы в сторону ФП. Хорошо это или нет - это вопрос открытый, но фраза о том, что C# остановится в развитии выдает незнание предмета обсуждения.

С другой стороны С++ - сейчас действует стандарт ISO/IEC 14882:2003, принятый, соответственно, в 2003-ем году. Следующий стандарт хотели принять в 2009-ом, но, походу, не выйдет. Для того, что бы уложиться в срок, новые предложения перестали принимать аж в 2006-ом. Из того, что уже было рассмотрено и планировалось к включению потом убрали концепты - одну из самых ожидаемых вещей. Рефлексии мы тоже не дождемся, сборки мусора тоже, области действия для макросов.

И кто, спрашивается, после этого "остановился в развитии"?

> Поэтому во время кризиса первыми вылетели с работы PHP-шники и C#

Да ну? А я наоборот сменил работу, перейдя заодно с С++ на С# :)

> так как их набрать из "школьников" в любой момент
> можно или обучить за 1-2 месяца. А С++ специалиста нужно
> обучать несколько лет, это "золотой фонд".

Вы, ИМХО, путаете квалификацию программиста и знание отдельного языка. Никакого "программиста на C#", как и на любом другом языке, вы за 1-2 месяца не сделаете. А уже состоявшийся программист изучит и C# и С++ в разумное и очень сравнимое время.

← →
jack128_ (2009-10-28 10:21) [52]

> Это восьмая была сугубо под нет. После они выделили его
> в отдельный продукт Delphi Prism - который развивается отдельно

delphi prism никакого отнашения кроме названия к той Delphi for .NET, которую писал борланд, не имеет. Это вообще плагин для мелкософтовской студии. просто эмбаркадеро его купило и продает под маркой дельфи.

← →
Rouse_ © (2009-10-28 10:30) [53]

> GDI+ (28.10.09 03:58) [48]
> А С++ специалиста нужно обучать несколько лет, это "золотой фонд"

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

← →
Anatoly Podgoretsky © (2009-10-28 11:03) [54]

> TIF (28.10.2009 01:45:44) [44]

Так это засланый казачок, Сиплюснутый Убийца

← →
Anatoly Podgoretsky © (2009-10-28 11:06) [55]

> Eraser (28.10.2009 01:47:45) [45]

Странно как то у тебя. "не имеют версии под *nix." и в тоже время на Маках тоже *nix.

← →
Anatoly Podgoretsky © (2009-10-28 11:07) [56]

> GDI+ (28.10.2009 03:58:48) [48]

И нафига такой язык, который надо 15 лет изучать и так и не изучить.

← →
Anatoly Podgoretsky © (2009-10-28 11:13) [57]

> Поэтому во время кризиса первыми вылетели с работы PHP-шники
> и C#,

Я сомневаюсь, что у тебя есть достоверная статистика, а не впечатления от недостоверных источников. И нафига PHP-шники в Микрософт и в Виндоус?

← →
Anatoly Podgoretsky © (2009-10-28 11:17) [58]

> jack128_ (28.10.2009 10:21:52) [52]

Как бы по определению любая студия это расширяемое с помощью плагинов, остальные компиляторы точно такие же плагины. Едиственно, что их сложно сделать, кроме Микрософта мало кто владеет технологией. А так бы не помешал плагин для ASP.NET в VS 2008

← →
b z (2009-10-28 11:31) [59]

> И нафига PHP-шники в Микрософт и в Виндоус?
Так Микрософт заявляет, что PHP под ИИС-ом шустрее работает чем под апачем. Да и еще много чего обещают, во - http://php.iis.net/ ;)

← →
Kostafey © (2009-10-28 13:20) [60]

> [53] Rouse_ © (28.10.09 10:30)
> идеальный обфускатор кода :)

Это что значит?

← →
Alkid © (2009-10-28 13:47) [61]

> Kostafey © (28.10.09 13:20) [60]
> > идеальный обфускатор кода :)
> Это что значит?

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

← →
Игорь Шевченко © (2009-10-28 13:57) [62]

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

Программам денег платить не надо ежемесячно

← →
Alkid © (2009-10-28 14:01) [63]

> Игорь Шевченко © (28.10.09 13:57) [62]

Имхо, не в этом главная проблема программистов-обфускаторов ;)

← →
Anatoly Podgoretsky © (2009-10-28 14:07) [64]

> Alkid (28.10.2009 14:01:03) [63]

Что они и без денег работать будут?

← →
Alkid © (2009-10-28 14:14) [65]

> Anatoly Podgoretsky © (28.10.09 14:07) [64]

Ну, за такую работу, которую они делают, они еще и сами приплачивать должны :)

← →
Anatoly Podgoretsky © (2009-10-28 14:40) [66]

> Alkid (28.10.2009 14:14:05) [65]

Вот и метод борьбы, и если работает то казачок засланый.

← →
Eraser © (2009-10-28 14:44) [67]

> [62] Игорь Шевченко © (28.10.09 13:57)

это смотря каким программам )

> [55] Anatoly Podgoretsky © (28.10.09 11:06)

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

← →
Alkid © (2009-10-28 14:53) [68]

> Anatoly Podgoretsky © (28.10.09 14:40) [66]
> Вот и метод борьбы, и если работает то казачок засланый.

ТК не одобряет такие методы воздействия :)

← →
Anatoly Podgoretsky © (2009-10-28 15:30) [69]

> Eraser (28.10.2009 14:44:07) [67]

Видимо очень сильно.

← →
GDI+ (2009-10-28 18:28) [70]

> Alkid © (28.10.09 09:36) [51]
>
>
> > GDI+ (28.10.09 03:58) [48]
> > И слава Богу, что тормозит. C# как был скриптомордием,
> так и останется.
>
> Аргументируй, что ли. А то мы тут на C# продукт пишем, а
> "мужики-то не знают!".
>
> > Поэтому во время кризиса первыми вылетели с работы PHP-
> шники и C#
>
> Да ну? А я наоборот сменил работу, перейдя заодно с С++
> на С# :)

Я тоже на C# пишу часть проектов. Но С# там чисто дополнительный - интерфейс и пр. Основная часть на С++. Но интерфейсную часть по чёткому техзаданию может писать и студент после двух месяцев обучения в IT-ПТУ.

Преимущество Delphi в том, что интерфейс и функционал можно писать на одном языке. И пусть функционал будет чуть менее эффективен чем на С++, но отличие небольшое. + Использование ассемблерных вставок разницу почти нивелирует.

А на C# нельзя прямо в код вставлять вставки на ассемблере. Поэтому для эффективной работы там и разумна связка C# + C++

← →
Eraser © (2009-10-28 18:33) [71]

> [70] GDI+ (28.10.09 18:28)

> И пусть функционал будет чуть менее эффективен чем на С++,
> но отличие небольшое.

отличие просто огромное. сейчас как раз портирую на Делфи часть одного крупного проекта на C++. Мне искрине жалко программистов, писавших его. Там огромное количесво кода - интерфейс. Еще больше кода - имитирование того, что уже давно есть в VCL. такой же проект на Делфи будет раз в 5 более компактнее и понятнее.

← →
Alkid © (2009-10-28 18:57) [72]

> GDI+ (28.10.09 18:28) [70]
> Преимущество Delphi в том, что интерфейс и функционал можно
> писать на одном языке. И пусть функционал будет чуть менее
> эффективен чем на С++, но отличие небольшое. + Использование
> ассемблерных вставок разницу почти нивелирует.

А что у вас там за функционал такой хитрый, что его на C# нельзя описать?

> Я тоже на C# пишу часть проектов. Но С# там чисто дополнительный
> - интерфейс и пр. Основная часть на С++. Но интерфейсную
> часть по чёткому техзаданию может писать и студент после
> двух месяцев обучения в IT-ПТУ.

У нас проект интеграционный, на базе ряда компонентов, писанных на С/С++ и C# делаем корпоративный продукт. Уверяю тебя, "ПТУшнику после 2-ух месяцев" там делать нечего, и не потому, что C# такой сложный, а потому что задача такая. Предыдущая версия продукта была целиком писана на С/С++ - и отдельные компоненты и интеграционная часть. Сравнив впечатления, решили, что все что позволяет окружение, будет переписано на C#. Собственно, С++ код таким образом почти исчезнет. Остается "ядерная" часть на С и "неядерная" на C#

← →
Дмитрий Белькевич (2009-10-28 19:18) [73]

Наши партнёры по интеграции отвечают нам:

Thanks! Hehehe, you still hold the record for fastest integration of our 3D
- no other partner came even close to you :)

Мы интегрируемся с ихней 3D библиотекой. Их либа (dll) - плюсы, наш экзешник - Delphi. Интеграцией как раз я занимался.

>такой же проект на Делфи будет раз в 5 более компактнее и понятнее.

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

← →
GDI+ (2009-10-28 19:19) [74]

> Alkid © (28.10.09 18:57) [72]
>
>
> > GDI+ (28.10.09 18:28) [70]
> > Преимущество Delphi в том, что интерфейс и функционал
> можно
> > писать на одном языке. И пусть функционал будет чуть менее
> > эффективен чем на С++, но отличие небольшое. + Использование
> > ассемблерных вставок разницу почти нивелирует.
>
> А что у вас там за функционал такой хитрый, что его на C#
> нельзя описать?

Например обработка видеопотока? Описать то можно, только тормозит сина-сина.

← →
GDI+ (2009-10-28 19:24) [75]

> Дмитрий Белькевич (28.10.09 19:18) [73]

Для рисования интерфейса C# и Delphi там действительно рулят. А вот различные библиотеки и функционал там уже С/C++.

Вот найдите более удобный и быстрый аналог fftw, пусть даже платный.

← →
Pavia © (2009-10-28 20:07) [76]

> Факт остается фактом. Корпорация MS правит балом, рынок
> ее огромен влияние также. MS говорит о своих планах. А в
> планах у нее C#.

МС более 20 лет раскручивали бесик -> визуал бесик->Net бесик.
А программы как писали на Си так и пишут. Причем раскручивала ничуть не меньше чем С#. Тот же C# 3 версии все более похож на бесик чем на Си.

> Для рисования интерфейса C# и Delphi там действительно рулят.
> А вот различные библиотеки и функционал там уже С/C++.Вот
> найдите более удобный и быстрый аналог fftw, пусть даже
> платный.

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

Есть тесты FFT прямой код без оптимизаций на си, делфи, java и net. Так вот скорости выполнения практически не отличаются.

> Те, кто работает на себя часто выбирают именно Delphi.

Те кто работает на себя выбирает по душе. Всех кого я знаю, кодят на разных языках. Комуто питон нравится. Кто-то на Java сидит. Я на Delphi. Другой друг на C++, а именно (QT) . Пятый балдеет от ассемблера и мата. Шестой на VBA.

← →
Delirium © (2009-10-28 20:51) [77]

И мои 5 копеек :). Мне сейчас предстоит проект на 3 года. Большой КИС с миллионом бизнес транзакций в день, я на полном серьезе рассматриваю вариант с Delphi 2010 + DevExpress в качестве средства для разработки толстомордых клиентов.

← →
Alkid © (2009-10-28 21:09) [78]

> GDI+ (28.10.09 19:19) [74]
> > А что у вас там за функционал такой хитрый, что его на
> C# нельзя описать?
> Например обработка видеопотока? Описать то можно, только
> тормозит сина-сина.

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

> Для рисования интерфейса C# и Delphi там действительно рулят.
> А вот различные библиотеки и функционал там уже С/C++.

Забыта важная область - бизнес-логика :) А ведь именно в ней обычно кроется значительная часть сложности приложений :)

← →
Игорь Шевченко © (2009-10-28 21:13) [79]

Delirium © (28.10.09 20:51) [77]

Привет, Антон!

> Большой КИС с миллионом бизнес транзакций в день

Но не Delphi же будет миллион транзакций окучивать, верно ? А что до толстомордого клиента, так и объемы будут поменьше, при такой ситуации вся нагрузка на базу/сервер приложений ложится, а от клиента требуется немного, но красивого.

← →
Alkid © (2009-10-28 21:16) [80]

> GDI+ (28.10.09 19:19) [74]
> Например обработка видеопотока? Описать то можно, только
> тормозит сина-сина.

Хотя, хочу заметить, основной источник тормоза в подобных задачах на C# - это принятая идеология безопасной работы с памятью, где исключен прямой доступ и арифметика указателей. В принципе, C# поддерживает unsafe код, в котором можно работать с указателями, только его применение напрочь убивает всю суть C# - удобство и безопасность.

← →
Delirium © (2009-10-28 21:23) [81]

> Но не Delphi же будет миллион транзакций окучивать, верно ?

Само собой :)
Проект довольно крупный - интегрируются несколько ИС-ов в единую ESB инфраструктуру. И пишется КИС заменяющая несколько текущих решений одним. Подразумевается множественный импорт / экспорт, куча очередей асинхронных вычислений и т.п. Ядро - несколько IIS-ов в локалке и возможно рядом стоящий BizTalk. А вот "морду лица", есть вероятность, на C# писать не будем - машинный парк слабый и программисты дорогие :)

← →
GDI+ (2009-10-29 01:29) [82]

> Alkid © (28.10.09 21:09) [78]
>
>
> > GDI+ (28.10.09 19:19) [74]
> > > А что у вас там за функционал такой хитрый, что его
> на
> > C# нельзя описать?
> > Например обработка видеопотока? Описать то можно, только
> > тормозит сина-сина.
>
> Да, пока managed-языки с такими задачами хуже справляются.
> С другой стороны, когда многоядерность будет реально массовой,
> все императивные языки будут сливать декларативным, где
> можно будет без крови и слез распараллеливать вычисления
> :)

Ну и на С++ OpenMP уже есть. Так что там где нужно то распараллелить можно без проблем на сколь угодно большое количество процессоров.

← →
Alkid © (2009-10-29 08:55) [83]

> GDI+ (29.10.09 01:29) [82]
> Ну и на С++ OpenMP уже есть. Так что там где нужно то распараллелить
> можно без проблем на сколь угодно большое количество процессоров.

Скажешь тоже :) OpenMp - это API, а я говорю о языке, где параллелизм поддержан на уровне самого языка. Сравни OpenMP и Erlang и почувствуй разницу.

← →
jack128_ (2009-10-29 11:36) [84]

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

а есть разница???

я так понимаю преимущество функ языков перед всякими дельфями/с++ в плане многопоточности заключается в том, что во всяких хаскалях нету изменяемых переменных, отсюда нет необходимости в синхронизации.

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

← →
jack128_ (2009-10-29 11:38) [85]

в том же haskell"е кстати многопоточность на уровне библиотеки реализована.

← →
Alkid © (2009-10-29 12:15) [86]

> jack128_ (29.10.09 11:36) [84]
> а есть разница???

Есть.

> в том же haskell"е кстати многопоточность на уровне библиотеки
> реализована.

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

← →
GDI+ (2009-10-29 19:46) [87]

Будущее за ИИ, а не функциональными языками. Это когда напишут такой фреймворк который под ситуацию сам будет конфигурироваться.

← →
Alkid © (2009-10-29 20:51) [88]

> GDI+ (29.10.09 19:46) [87]
> Будущее за ИИ, а не функциональными языками. Это когда напишут
> такой фреймворк который под ситуацию сам будет конфигурироваться.

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

← →
Демо © (2009-10-29 21:06) [89]

> Игорь Шевченко © (27.10.09 20:45) [20]
> > а вот на либой ширпотребный софт, либо специализированное
> > клиентское ПО спрос на версии под Mac сильно не дооценивают.
> > А примеры приложений с недооцененным спросом под Мак можно
> привести ?

Есть, например, такая программа, как 1С. Вот на Маке она не желает работать.
А многие хотели бы-)

← →
Игорь Шевченко © (2009-10-29 22:21) [90]

Демо © (29.10.09 21:06) [89]

> Вот на Маке она не желает работать.

Вот же. Говорят, и под линуксом несильно желает.

> А многие хотели бы-)

1С на Маке ? Извращенцы.

← →
Демо © (2009-10-29 22:29) [91]

> Игорь Шевченко © (29.10.09 22:21) [90]
> Демо © (29.10.09 21:06) [89]> Вот на Маке она не желает
> работать.Вот же. Говорят, и под линуксом несильно желает.
> > А многие хотели бы-)1С на Маке ? Извращенцы.

Увы... Есть такие. Накупит дизайнерская фирма маков, а бухгалтериия-то работает на 1С! Вот и начинают выкручиваться.

А работала бы на маках - замечательно!

← →
GDI+ (2009-10-29 22:29) [92]

> Alkid © (29.10.09 20:51) [88]
>
>
> > GDI+ (29.10.09 19:46) [87]
> > Будущее за ИИ, а не функциональными языками. Это когда
> напишут
> > такой фреймворк который под ситуацию сам будет конфигурироваться.
>
>
> Конечно. Только декларативность - необходимое условие работы
> этого ИИ. Пока ты сам будешь задавать как байты по памяти
> двигать, никакого ИИ не будет.

Хм, нейросети?

← →
Eraser © (2009-10-29 22:35) [93]

> [89] Демо © (29.10.09 21:06)

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

← →
Демо © (2009-10-29 22:43) [94]

> Eraser © (29.10.09 22:35) [93]
> > [89] Демо © (29.10.09 21:06)кстати, 1С это прекрасный
> пример программы, которая бы отлично работала бы и на джаве,
> ничем не хуже. другое дело, что когда разрабатывались младшие
> версии джава представляла из себя жалкое зрелище.

Согласен.
Java в конце 90-х и начале этого века была ещё недоразвитым продуктом.

← →
Игорь Шевченко © (2009-10-29 22:53) [95]

Демо © (29.10.09 22:29) [91]

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

← →
koha! (2009-10-29 23:01) [96]

жаль, что ламеризм прет типа VB.NET и С# А чем так Делфи всем не угадил? что его в поперают? ведь он еще не умер, но его уже харонят?

← →
Демо © (2009-10-29 23:04) [97]

> koha! (29.10.09 23:01) [96]
> жаль, что ламеризм прет типа VB.NET и С# А чем так Делфи
> всем не угадил? что его в поперают? ведь он еще не умер,
> но его уже харонят?

Т.е. ты считаешь VB.NET и C# - это продукт для ламеров? Или создан ламерами? Илм ламеры не могут научиться его использовать?

Что конкретно ты выбираешь?

← →
GDI+ (2009-10-29 23:29) [98]

> Демо © (29.10.09 23:04) [97]
> Илм ламеры не могут научиться его использовать?

Здесь проблема в унаследованном коде. Вот представьте приходите вы на работу в фирму которая выпускает продукт на C# написанный студентами. Продукт продаётся, но глючит. Ваша задача сделать его лучше.

Не станете ли вы матом разговаривать поле просмотра "унаследованного кода". И каким будет ваше решение по улучшению? Ведь радикальный вариант - всё переписать для профессионала неприемлем.

← →
Демо © (2009-10-29 23:31) [99]

> Не станете ли вы матом разговаривать поле просмотра "унаследованного
> кода". И каким будет ваше решение по улучшению? Ведь радикальный
> вариант - всё переписать для профессионала неприемлем.

Это перевёрнутая с ног на голову позиция.
Проблема не в продукте, а в ламеризме программиста. Не так ли?

← →
GDI+ (2009-10-29 23:48) [100]

> Демо © (29.10.09 23:31) [99]
>
> Это перевёрнутая с ног на голову позиция.
> Проблема не в продукте, а в ламеризме программиста. Не так
> ли?

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

Иногда это может быть несовместимость с какой-то системой или невозможность добавить в продукт какую-то функцию не сломав другие и пр.

Тоесть C# позволяет успешно писать код "write-only". В С++ такой код скорее всего сразу не заработает избавив от будущих проблем и дав понятие о квалификации разработчика.

PS
Сделайте систему, которой сможет пользоваться даже полнейший идиот, и только идиот станет ей пользоваться (с) Один из законов Мерфи.

← →
Anatoly Podgoretsky © (2009-10-30 08:56) [101]

> GDI+ (29.10.2009 23:29:38) [98]

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

> koha! (29.10.2009 23:01:36) [96]

Некоторым не угадил, а некоторым гадил.
А вот что такое поперают даже представить сложно, видимо что-то очень неприличное. И Харон тут при чем, он же только перевозчик, как такси, ему платить надо.

> Проблема в том что продукт позволяет...

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

> GDI+ (29.10.09 22:29) [92]
> Хм, нейросети?

Боже упаси! Нет.

> Здесь проблема в унаследованном коде. Вот представьте приходите
> вы на работу в фирму которая выпускает продукт на C# написанный
> студентами. Продукт продаётся, но глючит. Ваша задача сделать
> его лучше.

Очень просто - выпускайте продукт на C#, написанный не студентами, а нормальными программистами :)

Кстати, говнокода на С++, написанного студентами, я видел поболее, чем на C# :)

> koha! (29.10.09 23:01) [96]
> жаль, что ламеризм прет типа VB.NET и С# А чем так Делфи
> всем не угадил? что его в поперают? ведь он еще не умер,
> но его уже харонят?

Вы прослушали композицию "говнокод на русском языке".

Кстати, идиома "угАдить" - это шедеврально!

> GDI+ (29.10.09 23:48) [100]

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

Кстати, ошибочность твоей позиции прекрасно иллюстрируется наличием огромного количества "write-olny" говнокода на С/С++. Можешь мне поверить, я такие "гавниевы конюшни" наблюдал и наблюдаю...

А знаешь, в чем слабое место в твоей концепции? Нельзя инструментальными средством заставить людей писать хорошие программы или запретить им писать плохие. Это утопия. Квалификацию программиста, заработанную годами стажа и обучения, не заменит НИ ЧТО.

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

← →
Дмитрий Белькевич (2009-10-30 14:47) [106]

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

Угу, некоторые, "особенно выдающиеся", личности ставят компоненты в минусы Делфи.

← →
GDI+ (2009-10-30 17:30) [107]

> Дмитрий Белькевич (30.10.09 14:47) [106]

Ну в среде линуксоидов, как я заметил, ламер и Delphi-программист - слова синонимы.

> GDI+ (30.10.09 17:30) [107]
> Ну в среде линуксоидов, как я заметил, ламер и Delphi-программист
> - слова синонимы.

Слово "линуксоид" тоже в некоторых кругах считается бранным.

GDI+ (30.10.09 17:30) [107]

> как я заметил

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

← →
GDI+ (2009-10-30 19:27) [110]

> Игорь Шевченко © (30.10.09 19:23) [109]
>
> > как я заметил
>
> Среди таких же ламеров, как и ты ?
> Софт, ты почитай себя - ты ж натуральный ламер и есть

Угу, среди ламеров выигрывающих тендеры на многомиллионные проекты. Конечно, это еще ничего не говорит о квалификации программистов, но несколько коррелирует.

> Ведь радикальный вариант - всё переписать для профессионала неприемлем.

Я 3 года назад пришел в софтверную компанию, мне дали местную платформу и сказали - развивай и поддерживай :) Через пол-года я пролоббировал решение "всё переписать". Итог C++ ORM-ядро + VB5 клиенты превратились в C# и получили вполне конкурентный продукт, уже год продаем на нем решения... - непрофессионально конечно :)

← →
GDI+ (2009-10-30 19:43) [112]

> Delirium © (30.10.09 19:35) [111]

Ну так вы с С++ переписывали и ссылались на С# как новую платформу. А если бы это была как-то работающая платформа написанная студентами на C#. Тогда что? Java?

> GDI+ (30.10.09 19:43) [112]

Дело не в плюсах и C#, а в том, что со временем требования меняются и, как следствие, софт должен переписывать полностью и на новых средствах, а не поддерживаться до бесконечности.
А студенты должны реализовывать интерфесы и наследовать классы написанные более опытными товарищами, а не лезть в корневой код. За этим призваны следить ведущие, за ведущими смотрят аритектора и эксперты, и всех пинают ПМ-ы с аналитиками. Если не экономить на инфаструктуре, то и говнокода не будет.

← →
GDI+ (2009-10-30 20:08) [114]

> Delirium © (30.10.09 19:52) [113]
> А студенты должны реализовывать интерфесы и наследовать
> классы написанные более опытными товарищами, а не лезть
> в корневой код. За этим призваны следить ведущие, за ведущими
> смотрят аритектора и эксперты, и всех пинают ПМ-ы с аналитиками.
> Если не экономить на инфаструктуре, то и говнокода не будет.

Смотря где. Если разработка идёт в госконторе(всяких НИИ и пр), то к получившемуся ПО применим термин "чуть-чуть работает". Там студенты и есть "ПМ-ы с аналитиками".

> Если разработка идёт в госконторе

Не могу согласиться на 100%, да есть отдельные артефакты, однако, сейчас государство, как правило, сливает любые разработки в конкурсы и отмывает бабло, а что до кода - пишется он софтверными компаниями и не плохо, но зачастую - в стол.
А вот корпоративный IT все ещё пытается экономить и вместо того, чтобы пустить к себе консалтинг, а вслед за ним - профессионалов-программистов - изобретает велосипеды от которых волосы шевелятся везде :)

> GDI+ (30.10.2009 17:30:47) [107]

Какие они гада, а на самом деле это они сами это слово.

> Угу, среди ламеров выигрывающих тендеры на многомиллионные
> проекты. Конечно, это еще ничего не говорит о квалификации
> программистов, но несколько коррелирует.

Люди как правило многолики, скажем ламер в программирование, но а в обдуривание клиентов. Так и не надо его пускать в программирование, пусть деньги клепает для конторы.

← →
GDI+ (2009-10-30 21:05) [118]

> Anatoly Podgoretsky © (30.10.09 20:25) [117]
>
>
> > Угу, среди ламеров выигрывающих тендеры на многомиллионные
> > проекты. Конечно, это еще ничего не говорит о квалификации
> > программистов, но несколько коррелирует.
>
> Люди как правило многолики, скажем ламер в программирование,
> но а в обдуривание клиентов. Так и не надо его пускать
> в программирование, пусть деньги клепает для конторы.

Точно про Microsoft.

> GDI+ (30.10.09 19:27) [110]
> Угу, среди ламеров выигрывающих тендеры на многомиллионные
> проекты. Конечно, это еще ничего не говорит о квалификации
> программистов, но несколько коррелирует.

Проекты на Дельфи и C# тоже выигрывают многомиллионные тендеры. И что из этого следует?

← →
GDI+ (2009-10-30 21:33) [120]

> Alkid © (30.10.09 21:19) [119]
>
> Проекты на Дельфи и C# тоже выигрывают многомиллионные тендеры.
> И что из этого следует?

А где я говорил что я не пишу на Delphi и C#? Я просто говорил что простота языка никоим боком не коррелирует со сложностью проекта. Поэтому выбирать язык только за то что он простой можно только разве что для одноконного приложения написанного за пару дней.

А В целом разницы в простоте для сложного проекта нет ни для Delphi, ни для C# ни для C++. Но в некоторых случаях при использовании определённого языка можно получить преимущество.

Например если разница в производительности в три раза для казуальных игр или ворд-процессоров незаметна на глаз, то для серьезного 3D-шутера 30% проиводительности играют роль, вплоть до разгона системы под жидким азотом.

> GDI+ (30.10.09 21:33) [120]

Очень хорошо, тогда к чему эти замечания про линуксоидов, синонимы, ламеров, скриптомордия и многомиллионные тендеры?

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

А кто-то утверждал, что простота языка является определяющим критерием выбора? В каком сообщении.

> А В целом разницы в простоте для сложного проекта нет ни
> для Delphi, ни для C# ни для C++. Но в некоторых случаях
> при использовании определённого языка можно получить преимущество.

Это спорное утверждение. Например, С++ не поддерживает концепцию модульности, что осложняет организацию больших проектов

> Игорь Шевченко © (30.10.09 21:41) [121]

Ну, вообще он мне троллем не показался. Скорее у него просто хороший заряд "С++-ного снобизма".
Я сам был одно время таким.

← →
GDI+ (2009-10-30 22:34) [123]

> Alkid © (30.10.09 22:04) [122]
> > для Delphi, ни для C# ни для C++. Но в некоторых случаях
> > при использовании определённого языка можно получить преимущество.
>
> Это спорное утверждение. Например, С++ не поддерживает концепцию
> модульности, что осложняет организацию больших проектов

Я ж и говорил - интерфейс и "лёгкая" бизнес-логика на C# а тяжелые функции в библиотеки на С/С++, возможно со вставками асма.

> Например, С++ не поддерживает концепцию модульности, что
> осложняет организацию больших проектов

Windows большой проект ? (написан на С, очень небольшая часть на С++)
Oracle большой проект ? (аналогично)
Firebird, исходники доступны, можно посмотреть (аналогично)
Линукс большой проект ?

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

> Alkid (30.10.2009 22:04:02) [122]

В С++ легко выстрелить себе в ногу.

> GDI+ (30.10.2009 22:34:03) [123]

Дельфи тоже неплохо вставляет АСМ

← →
Дмитрий Белькевич (2009-10-30 23:01) [127]

Делфи отлично работает совместно с ассемблерными вставками, да и сам генерирует весьма качественный код, который сопоставим по скорости с плюсами. Весь вопрос в алгоритмах. Я, например, совместно с нашим математиком, реализовывал один, достаточно сложный, специфический рассчетный алгоритм (MPR - Multi Planar Reconstruction) он по скорости существенно обгоняет конкурентские, написанные на плюсах. Алгоритм написан полностью на Делфи. И даже в этом случае я не делаю никаких выводов, о том, что Делфи существенно обгоняет плюсы по скорости, а всего лишь выводы, что мои алгоритмы работают оптимальнее.

> Игорь Шевченко © (30.10.09 22:46) [124]

Ваши слова не противоречат моим.

> Anatoly Podgoretsky © (30.10.09 22:48) [125]

Каноничная фраза Страуструпа звучит так:
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off."

> GDI+ (30.10.09 22:34) [123]

Поясни, какой смысл ты вкладываешь в понятия "лёгкий" и "тяжёлый" в данном контексте. Производительность?

← →
GDI+ (2009-10-30 23:42) [129]

> Anatoly Podgoretsky © (30.10.09 22:49) [126]
>
> > GDI+ (30.10.2009 22:34:03) [123]
>
> Дельфи тоже неплохо вставляет АСМ

Зато на Delphi нет 64-бит до сих пор (реальное опоздание на 4 года, другие проекты были бы уже объявлены мёртвыми, если бы Delphi не был бы так хорош в другом) и нативная полная поддержка Unicode только с Delphi2009.

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

Вывод - если писать под Wintel + 32-bit - Delphi2009 сейчас идеальная платформа для этого. Если нужно что-то еще - уже нужно думать о других решениях.

← →
GDI+ (2009-10-30 23:47) [130]

> Alkid © (30.10.09 23:12) [128]
> > GDI+ (30.10.09 22:34) [123]
>
> Поясни, какой смысл ты вкладываешь в понятия "лёгкий" и
> "тяжёлый" в данном контексте. Производительность?

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

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

> GDI+ (30.10.09 23:47) [130]

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

← →
GDI+ (2009-10-31 00:40) [132]

> Alkid © (31.10.09 00:16) [131]
> В силу ряда свойств
> C# лучше подходит для управления этой сложностью, чем С++.

Если у вас язык управляет сложностью, тогда я точно не хочу там работать. Так как бардак на C# делается так же просто как и на C++. К тому же его там можно замаскировать.

Hsilgos :Ты знаешь про время жизни объекта?
Hsilgos :Так вот...
Hsilgos :Из метода передавался в объект ( который работает в ДРУГОМ потоке ) адресс локальной переменной
Hsilgos :Представляешь, что случается, когда метод выходит?
Hsilgos :Правильно, локальная переменная уничтожается.
Hsilgos :Адресс становится инвалидным
Hsilgos :А так как объект, в который передается этот адрес - работает в другом потоке, то это вполне реальныя маза.
Hsilgos :Я на это втыкаю долго... И иду спрашивать, как это работает?
Hsilgos :Ведь ясно же, что это ошибка.
Hsilgos :На что мне чувак говорит : ставлю у потока более высокий приоритет и благодаря этому объект УСПЕВАЕТ вычитать содержимое переменной
Hsilgos :А ты говоришь - "Архитектура"... "Планирование"...
Hsilgos :Индийцам до нас далеко
Hsilgos :Чисто по-русски. Успеть хапнуть, пока не пришел писец...
http://bash.org.ru/quote/217723

Это я к тому, что не все ошибки может исправить "компилятор".

> IsDelphiDead

No

А вот что хотят с ним сделать в ближайшем будущем, а также на что делают ставки в Embarcadero, поможет узнать проводимый ими опрос-исследование:
http://edn.embarcadero.com/article/40071

Там очень много вопросов, включая те, которые касаются известных многим обещанных x64, кроссплатформенности (в том числе iPhone и др. мобильных платформ) и т.п., но есть и кое-что новенькое: cloud computing, social networks, создание "Components Store" (то бишь аналог всяких App Store, только по продаже компонентов :), а также меня порадовал вопрос про локализацию студии на другие языки. Проголосовал конечно же за Russian. Вообще-то они ещё в 2008 году обещали локализацию... Может не так уж долго ждать осталось :)

(* Дабы предотвратить возможные комментарии не совсем в тему: да-да, русификация IDE - это "ваще песец", english - наше всё, но однако локализованные средства разработки успешно выпускаются и спрос на них есть... *)

> TIF (31.10.2009 01:41:13) [133]

Ничего не пропускают, хватаются за все, что в газетах написали.
Политика нахватать дешевых популярных решений и впихнуть их в VCL, остальное не важно.

> GDI+ (31.10.09 00:40) [132]

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

← →
jack128_ (2009-11-02 10:56) [136]

Alkid © (29.10.09 12:15) [86]
> А при чем тут Хаскель? Он никогда не позиционировался как
> язык, заточенный под параллелизм.

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

> jack128_ (02.11.09 10:56) [136]

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

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

В общем, работы в этом направлении еще хватает.

← →
Дмитрий Белькевич (2009-11-02 18:17) [138]

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

> Дмитрий Белькевич (02.11.09 18:17) [138]
> В любом случае, я слабо себе представляю как, например,
> распараллелить чтение файлов с диска в память

Очень просто - организовать raid-массив или распределённое хранилище.
Если файл находится на одном диске, то, понятное дело, распараллеливать тут нечего.

> на остальное юзеры не жалуются - хватает обычных тредов.

Впервые слышу, что бы юзеры жаловались на чтение файла в одном потоке :)

Речь, конечно же, идет о распараллеливании вычислений.

← →
Дмитрий Белькевич (2009-11-02 18:54) [140]

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

На одном.

>Впервые слышу, что бы юзеры жаловались на чтение файла в одном потоке :)

Бывает и не такое, да :)

>Речь, конечно же, идет о распараллеливании вычислений.

У меня пока что получается всё считать в реалтайме. MMX"а, максимально возможной оптимизации алгоритмов и одного ядра хватает.

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

Опять же - можно посмотреть в сторону CUDA и иже - там и ядер побольше и ядра получше (в плане вычислений).

> В любом случае, я слабо себе представляю как, например,
> распараллелить чтение файлов с диска в память

Читать с разных смещений в файле ? Способ довольно широко используется...

> Дмитрий Белькевич (02.11.09 18:54) [140]
> На одном.

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

> У меня пока что получается всё считать в реалтайме. MMX"а,
> максимально возможной оптимизации алгоритмов и одного ядра
> хватает.

От задачи зависит.

← →
Дмитрий Белькевич (2009-11-02 19:20) [143]

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

О чем и речь.

>От задачи зависит.

Согласен, случаи всякие бывают.

> Alkid (02.11.2009 19:06:22) [142]

Пропускной способности шины хватает с избытком, узким место является количество оборотов, но РАИД может изменить все это.

IsDelphiDead.com Найти похожие ветки