» На каком языке программируете ?

Цитата:

Delphi (или Object Pascal, если быть корректней), по моему глубокому убеждению, является полноценным языком

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

Цитата:

математические программы - на Фортране

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

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

Ну на счет Perl ты брат не прав... И какого рода программа тебе нужна? И что ты называешь программой? На Perl пишутся полноценные приложения даже под Винду про Unix и Linux я вообще не говорю!

Quickspider

Цитата:

Например, клиент-серверные приложения гораздо удобнее писать на С, чем на Delphi

Вы действительно так считаете? Поподробнее можно?

Pryth

Цитата:

Языки вроде perl, java, vbscript я не брал, т.к. хочется узнать на каком языке пишут программы, а не скрипты и т.п.

Да такой лажи типа этой цитаты я не слыхал - это же надо язык Java спутать с Java Script - абсолютно разные языки для различных задач и ни какой паскаль или там бейсик и в сравнение не идет с джавой
так что Pryth думай а потом обижай людей

мой яязык - ProLog

Цитата:

это же надо язык Java спутать с Java Script

Понимаю, если еще некоторые фрагменты Java с Си++ спутать, это еще куда ни шло

Если кому интересно, то пишу на Delphi, а лучший язык тот, который занешь лучше!
Я например, не встречал задачи, которую можно сделать только на одном языке и нельзя на другом.
А конкретная реализация зависит от головы и рук программиста.

Я пишу клиент-серверные торговые системы и использую связку Delphi+IB(FB)Yaffil. И хочу начать писать web, но времени на изучение не очень много.

Добавлено
dremon
Скажи, а есть вообще среда с нормальным управлением проектами?

А про Delphi. Что думаешь насчет TeamSource в поставке Delphi?

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

например realtime анализ большого колличества аудио или (значительно меньшего колличества) видео потоков нельзя сделать ни на джаве, ни на перле, ни даже просто на С/C++.

То есть на первых 2х совсем плохо а на C/C++ без жестоких ассемблерных вставок тоже тормохит...
Тут для выигрыша миллисекунд и компилятор лучший (KAI) покупаешь и все мануалы по оптимизации под определенный проц перерываешь..

Обычно tight loop - часть кода, критичная к скорости, весьма мала - в примере с обработкой видео это будут дискретные преобразования матриц. Такую часть действительно иногда переписывают на ассемблере, но остальные 99% (которые часто занимают меньше 1% времени счета) пишут на языке высокого уровня - хоть на Яве.

Кстати, KAI официально мертв.

varjag
но остальные 99% (которые часто занимают меньше 1% времени счета) пишут на языке высокого уровня - хоть на Яве.
ты видимо достаточно однобоко знаком с процессингом аудио и видео..то есть наверно есть такие системы в которых мелкая критическая часть кода а остальное настолько расслаблено настолько что пофиг на чем писать, но таких систем единицы.

Пример реальной системы А/В процессинга.
6 ассемблерных модулей в критических участках.
остальное написано на С++ и компилено КАИ

Юзерские приложения репорта и тд, некритичные к машинному времени действительно написаны на жабе, и соединяются с основной системой через CORBA, но вся эта жаба не входит в CORE System.

Даже при компиляции С++ через ГЦЦ Core System тормозила на подключении 3его видеопотока видео или 40какого-то потока аудио на 2процовый Пень3 (я долго пытался людей на Атлон перетащить но не вышло (( )

Так что всё ядро системы на Жабе и тд никогда не пишется,...

А насчет КАИ - это для меня один из самыз страшных ударов по линуксу ((( , Интел конечно кидает пальцы мол у низ всё это в компайлере будет...но знаю я их ... и близко не подойдут...

qusejodan

Кодеки видеопотоков я не писал, но кодек JPEG приходилось, так что представление о предметной области имею.
Есть такая вещь, профайлер называется - показывает сколько времени программа проводит в каждом участке кода. Так вот, подавляющее большинство программ имеют одно-два узких места, составляющих пару процентов кода. Например, в моем кодеке узким местом был array reference, в силу того что я использовал язык с обязательной проверкой границ.
Ну не может весь код в реальном проекте быть одинаково вычислительно интенсивным! Оптимизировать *всю* кодовую базу - мазохизм и извращение, приводящее к низкой портабельности, бесполезной трате девелоперского времени и плохой сопровождаемости.
"Незрелая оптимизация - корень всех зол" (c) Д. Кнут.

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

2. Кодек джпега и кодеки видео имеют не так много общего как ты думаешь.

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

4. Если имеешь дело не с программой которая занимает всё компьютерное время одним thread'ом, а с многопоточной программой каждый поток которой обязан процессить свой видео "поток" (извиняюсь за двойственнсть) а потом обмениваться с кем нибудь результатами, то самая мысль написать что-либо кроме клиента к core-system на интерпретируемом языке, или на плохо оптимизированном (но в этой части уже не вручную, а компилятором) компилируемом языке вызовет подозрение в сумасшедствии....

" быть одинаково вычислительно интенсивным"
никто про одинаковую интенсивность и не говорил.

На некритичных участках кода KAI вполне хватает..
а g++ уже нет .. теперь представь, что будет если подставить жабу.

> 2. Кодек джпега и кодеки видео имеют не так много общего как ты думаешь.

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

> а некритичных участках кода KAI вполне хватает.. а g++ уже нет ..

Да ну, даже на вводе-выводе g++ надрывается?

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

>Да ну, даже на вводе-выводе g++ надрывается?
Со злости
Скажи ты думаешь над тем что говоришь?
представляешь себе программу в которой этот самый ввод-вывод занимает ну 5% всего времени?
И что мне теперь его оформлять отдельным модулем и специально только его g++ ом компилить а всё остальное - KAI..

И пойми что пока один поток выполняет свой ввод вывод параллельно еще 5-6 выполняют жестокий процессинг. Тут на чём угодно начинаешь экономить.

"- попробуй profiler"
Опять-таки со злости...как инженер у инженера спрошу, ты видел хоть одного инженера работающего на рельном проекте который бы не пользовался профайлером. ВСЁ 10 раз прощитывалось, обсуждалось, и тд.
Или ты думаешь деньги на компайлер просто так дают?
Типа нужна игрушка, ну возьми - купи...Пока не докажешь, что реально нужно хрен тебе больше 300 баксов на программный продукт выделят...ак KAI как наверно догадываешься "чуть" поболее стоит.

qusejodan

Цитата:

а на C/C++ без жестоких ассемблерных вставок тоже тормохит...

Ерунда.
Ты можешь оптимизировать код вручную лучше, чем современный компилятор? С планировщиком, разворачиванием циклов, удалением подвыражений, распараллеливанием и глобальной межмодульной оптимизацией? Очень в этом сомневаюсь. Сидеть с таблицами машинных инструкций полгода и считать выигрыш в циклах - это нечто из древних времен.
Сейчас на ассемблере пишут только машинно-зависимые участки кода, но никак не оптимизацию. Я занимался промышленными real-time разработками 4 года, ассемблер мы использовали только для операций дискретного и аналогового ввода/вывода. Даже многозадачное ядро было написано полностью на C++. Пытались переписывать критические части кода на ассемблере, максимум это давало прирост производительности в 1 процент после многих недель ковыряния и отладки.

dremon,
Именно машинно зависимые модули это и были (извини если недостаточно ясно выразился)

6 асемблерных модулей...прирост производительности в !огромен! ну чуть меньше на пару десятых...
для сравнения
Раньше при загрузке более 3300 аудио-"моделей"
функцианирование в tiempo real прекращалось.
Теперь можно грузить на один нод порядка 18000 моделей.



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

> представляешь себе программу в которой этот самый ввод-вывод занимает ну 5% всего времени?

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

> ты видел хоть одного инженера работающего на рельном проекте который бы не пользовался профайлером.

Поверь, я видел еще и не такое.

повышение локальности данных для снижения промахов кэша

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

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

И начиналось всё с однокомповой, однопотоковой системы способной идентифицировать 2 000 (в среднем)
"образцов" (не путать с sample ) аудио.
а теперь и несколько видеопотоков жрет одновременно и 18 000 моделей аудио на 1 нод модно закинуть... в общем сказка прямо а не система...

Delphi - Rulez...

Я могу писать на следующих языках:
Basic/Visual Basic
C/C++
Pascal/Delphi
Но предпочитаю Pascal/Delphi

кодирую на
C/C++
asm
VB
Delphi

Delphi, Pascal, Opject Pascal как хотите его называете, но по-моему мнению он будет рулить. Сейчас ему просто недостаточно известен, чтобы обогнать Си, но по понятности синтаксиса он Си превасходет (общепризнанный факт), а сам Старуструп писал: "Нужно пожертвовать скоростью ради понятности" (неточная цитата)

I am programming on Java.

Fortran for Windows 4.0

На Делфи...Издеваюсь...Все учебник не найду.

Цитата:

Fortran for Windows 4.0

Ого! Респект - поддерживаешь российского производителя?

Пишу на такой штуковине
eMbedded Visual C++ 3.0
Но Delphi больше нравится!

Цитата:

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

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

Цитата:

Это изначально был академический язык

Согласен...

Цитата:

Таковым и остался

А где аргументы?

Цитата:

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

Другим языкам???
Ну ка приведи хотя бы 3 примера? И аргументы?
Базар фильтруй! Я тя за Дельфи...
Хотя бы скажи чем оно хуже Билдера?

UncoNNecteD

Да даже синтаксисом (У Си синтаксис значительно удобнее чем у Паскаля)!!!!!!!!! Чего токо begin и end стоят!
Да и функциональными возможностями Си исть Си. Он изначально создавался как альтернатива Асемблеру на высоком уровне.