IsDelphiDead.com

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

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

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

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

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

← →
Игорь Шевченко © (2009-10-30 21:41) [121]

Alkid © (30.10.09 21:19) [119]

> И что из этого следует?

Из этого следует, что не надо кормить тролля

← →
Alkid © (2009-10-30 22:04) [122]

> 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# а тяжелые функции в библиотеки на С/С++, возможно со вставками асма.

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

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

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

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

← →
Anatoly Podgoretsky © (2009-10-30 22:48) [125]

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

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

← →
Anatoly Podgoretsky © (2009-10-30 22:49) [126]

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

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

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

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

← →
Alkid © (2009-10-30 23:12) [128]

> Игорь Шевченко © (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# может даже быстрее будет, так как оптимизирован под работу со строковыми переменными.

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

← →
Alkid © (2009-10-31 00:16) [131]

> 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

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

← →
TIF © (2009-10-31 01:41) [133]

> IsDelphiDead

No

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

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

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

← →
Anatoly Podgoretsky © (2009-10-31 10:31) [134]

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

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

← →
Alkid © (2009-10-31 10:33) [135]

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

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

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

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

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

← →
Alkid © (2009-11-02 11:07) [137]

> 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 Найти похожие ветки