Ведь тут еще один аспект: код, получаемый из С++ будет очень эффективным на машинах лини DEC. Именно там команды, подобные *а ++ = *в ++ будут переводится в минимальное количество инструкций прцессора, но никак (без оптимизационной работы) на архитектуре х86. Собственно сам синтаксис С/С++ обязан своим рождением набору команд PDP-11. А в самой Интел до недавнего времени использовался PL/M, который ну никак на С не смахивает. Более строго, семантический разрыв между набором команд Интелов и С шире чем между PDP и С. А, следовательно и работы компиляторам, для преодоления этого разрыва приходится делать больше (и времени затрачивать на компиляцию). А теперь подумайте о том, что на Паскале таких наворотов нет... Еще один момент: С(С++) на низком уровне опирается на конкретный вычислительный механизм (по признанию автора) - указатели, регистры, возможность доступа к результатам последней операции и т.д. Паскаль же в этом отношении более абстрактен и не привязан к архитектуре компьютера. 

Мне известны только две операционки, написанные ИЗНАЧАЛЬНО ПОЛНОСТЬЮ на языке высокого уровня - и это не UNIX. Почитайте где-нибудь о Лиллит и Оберон. 

Можно вспомнить и отечественный Кронос, ставший жертвой коллапса СССР и его электронной промышленности. Там, правда, Модула-2 с асмом, но Си вообще не рассматривали даже, ибо уже понимали, что дыра.

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

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

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

Дело в следующем: Да я согласен - в Си++ введены более строгие правила совместимости типов (по сравнению с Си), да у него очень мощная объектная модель, да и др..... 

Но! Но ведь одним из основных требований к Си++ является обратная совместимость с Си. К чему это я? Да к тому, что в самой глубине, на самом нижнем уровне реализация всех управляющих конструкций, структур данных (управление ими) - это по сути дела тот же самый Си. Вспомните, например, как реализован и поддерживается тип XXXXXString в любой из реализаций Си++. Ведь в этом классе обязательно есть поле char* - а это уже источник потенциальных ошибок! Нет, как раз со стрингами может и нет никаких проблем. Здесь проблема общего плана. Это, часто превозносимый подход, при котором смешиваются указатели и массивы. Сама возможность «гулять» по памяти с помощью операций арифметики над указателями не имеет никакого смысла в языке высокого уровня. «Память» и «адрес» - это не понятия языка, не опирающегося на конкретный вычислительный механизм. Более подходящим для такого рода языков является понятие ссылки на объект (не важно какой природы). Значением же такой ссылки является нечто (неконкретизируемое), что позволяет определить объект, на который у нас имеется ссылка или NIL - ссылка ни на что не ссылается. Из операторов, к ссылке применим только оператор присвоения. Из всех операций разрешена только операция сравнения (равен - не равен). Это помогает выявить пустую ссылку и проверить тождественность объектов для разных ссылок. В Компонентном Паскале вообще существует только два вида указателей: на массив и на запись. И, при здравом размышлении, становится понятно, что это является сильнейшим средством избежать многих проблем. Ну, в самом деле, что такое УКАЗАТЕЛЬ НА ЦЕЛОЕ? Для чего я его могу использовать в языке высокого уровня (по Вирту)? Выделить память и хранить одно целое? Смысл? Если это временная переменная... Вернее так: в процедуре, если мне нужна временная переменная, то я ее просто объявлю локальной и она благополучно помрет при выходе из процедуры. Глобальнае переменная (в данном случае - целая) по сути своей (по сроку существования) не может быть «временной». Хранить в указателе на целое адрес массива целых ( одно- или многомерного массива?????)? И потом вводить дополнительные переменные для количества измерений и величин размерностей массива? Ну хорошо, все это прячется в классы. Придумываются и пишутся перегруженные операторы присвоения, конструкторы копирования. Но ведь проблема никуда не делась, она лишь запрятана внутрь библиотек классов. Куда только хваленая эффективность девалась? А мы ее на разные проверки истратили. Там, внутри классов! 

© Владимир Лос "К вопросу о выборе языка программирования. Часть II" 1999.

Или если коротко, вычислительной архитектурой должен заниматься компилятор, а не программист. Довольно сомнительно и использование Си-подобного синтаксиса в языках 90-2000-х годов, ну подчистили совершенно маразматичные конструкции плюсов, но общая мутность от этого никуда ведь не делась. Да и у меня была инфа, что на 2004-ый год, 60% программистов в мире использовали Visual Basic, что в принципе похоже на правду, учитывая, что 80% программистов даже не работают в фирмах, которые производят ПО. Delphi как раз и покрывала этот слой в странах, где Паскаль в почете, но помимо этого тащила и часть задач, решаемых в США, обычно, на плюсах.

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


Не, их естественно решать с помощью парсерных комбинаторов. Или например ANTLR.


Это в "исключительно мощной и удобной объектной модели Object Pascal'я". В нормальных ОО-моделях такой проблемы нет.


Нет, т.е. лучше один раз увидеть, чем сто раз услышать.

Мы вроде как о Си говорили, Вы зачем-то сюда ещё и C++ добавили, да и ещё с Паскалем начали сравнивать, зачем?
По поводу первого абзаца. Я не очень понял, к чему он был написан. Код написанный на Си долго компилируется? Или это к тому, что у всех процессоров разная архитектура и набор команд? И нужно писать компилятор под каждый процессор? Или что? Я не очень понял мысль, разъясните, пожалуйста. 
И я бы не назвал Си выкоуровневым языком.


Можно подробней? Насколько мне известно, не обязательно использовать char для хранения строк.


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


Ни разу не занимался вычислительной архитектурой, программируя на С++. Я делаю что-то не так?

Или что Вы понимаете под вычислительной архитектурой?


Это сообщение отредактировал(а) Guinness - 19.4.2013, 09:14

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

Ну там я и другой пример приводил, да и о реализации линк-запросов упоминал, а этот пример просто дает общее представление. Можно и другие примеры привести, например библиотека WebSharper, позволяющая удобно разрабатывать веб-приложения на этом языке, используя quotations транслирует код javascript, позволяет описывать HTML следующим способомВ результате будет сгенерирован следующий хтмлПример взят отсюда.


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

Это тоже программирование... функциональное  

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

Интересно, что бы это могло быть?

Она будет выглядеть офигенно!
Слово "неплохо" скорее применимо к некоторым технологиям 10х, когда сравниваешь их с делфей 90х. Однако ж и "неплохо" тут несколько преувеличено. Скорее "ну да, не плохо "

Вот этот вопрос меня и ставит в тупик. Что случилось в отросли за 20 лет. Ничего. Никаких прорывов, революций. 


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

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

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

"Серебрянной пули нет" Брукса читали? Да и вообще, "Мифический человеко-месяц"? Он ещё в 87 году про это написал.

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

Ну почему? Я тебе приводил несколько примеров. В чем из того, что тебе приводил ты попытался разобраться? Все, что перечислили дельфисты в том или ином виде есть много где. Из того, что перечислял я, в дельфах ничего нет. Тем более дельфисту ознакомиться несложно, для начала можно тот же призм начать курить с его оксигеном. Ты этого не сделал, но комментируешь. А что до функциональщины, ну приводились же примеры, вон SKrivosein пошел F# учить  , стало быть аргументы звучали.

Делфисты просто проспали всё это время.   

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

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

Я же уже показывал на примере MODEL. Штука забавная, милая, но ты ведь тоже не погрузился в ее изучение и не проникся ущербностью MSSQL перед Ораклом. Почему? Я полагаю потому, что прочих бенефитов, кроме разминки головного мозга, эта плюшка тебе вряд ли принесет. Я тебе могу привести в пример еще пару-тройку десятков преимуществ, которые я не просто использую в повседневной жизни, но и которые позволяют мне строить эффективные приложения на платформе оракла. Часть из них ты найдешь забавными, часть найдешь спорными, но погружаться, углубляться в изучение этих плюшек ты пустишься вряд ли. Тем более вряд ли, ты примешь на этом основании решение о смене платформы БД. Почему? Я полагаю потому, что те задачи, которые решаю я, ты тоже можешь решать. Пусть и по другому. Пусть и менее удобно. Пусть и с целым рядом допущений... но можешь.

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

Понятно, что понятие киллерфичи - субъективно и контекстозависимо. И вобще, может не иметь отношение к продукту как к таковому (тот самый рынок труда, как пример)


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

Это сообщение отредактировал(а) Zloxa - 19.4.2013, 10:54

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

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