Языческие разборки.

Сабж тут.

Zeus>Сила Паскаля как раз во многом в его ограничениях: этого нельзя, здесь строго так и т.п... При правильном подходе это помогает писать стройные и ясные программы.

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

На любом ЯВУ можно решить любую задачу, возможную на другом.

Вопрос в эффективности.

Так вот, ИМХО, ни по эффективности программирования, ни по надёжности, Паскаль оптимальным не является. Более лаконичные конструкции - пожалуйте C++ (или Perl тот же - вообще сказка). Большая надёжность - вот вам Ада - куда уж круче-то? Расширяемость и меньший уровень скрытых ошибок? - Forth, извлечение табличных данных - SQL...

ИМХО, сравнивать надо таки конкретные ЯВУ, а не pas vs all. Ибо так можно закритиковать насмерть любой язык. Типа: скорость хуже чем у асма, надежность меньше чем у ады, замороченность меньше чем у cи etc. Кроме того, надо определиться с диалектом паскаля. Предлагаю Object Pascal vs C++. Да, и сравнивать именно языки, а не IDE, библиотеки и протчие наслоения..

quote:

---

ни по эффективности программирования, ни по надёжности, Паскаль оптимальным не является.

---

 

ИМХО, по совокупности данных параметров OP оптимальней чем С++.

Хотя, ИМХО, понятие оптимальности неразрывно связанно с решаемой задачей. Так что придется ещё и задачу специфицировать.. В противном случае опять получим сотрясание воздуха..

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

Для меня Паскаль - это известный мне уже почти тридцать лет язык (я имею в виду, начиная с Алгола). Я умею выражать на нём свои мысли и понимаю программы, написанные на нём.
Программы, которые я пишу, делают то, что я хочу. Всегда.
На фиг мне сдались все остальные языки? Да я лучше ЭВМ сделаю, которая будет понимать меня, то есть Паскаль. Слава Богу, возможности есть... . Злоупотребление служебным положением, понимаешь...

quote:

---

приведи примеры задач, где OP смотрится лучше, чем C++?

---

 

Скажем так: проекты средней и выше степени сложности с повышенными требованиями к надежности.

Поскольку меня месяц не будет, то изложу вкратце тезисы.
1. OP - ЯВУ, С++ - макроасм. переросток.
2. На ОР нужно приложить дополнительные усилия, чтобы сделать программу менее надежной, на С++ наоборот.
3. Читабельность исходников на ОР выше, т.е. надо прилагать меньше усилий для этого.
4. ОР не уступает С++ в скорости выполнения и объему кода.

Просвятите пожалуйста.

Как-то глядя в код ОП С++-программист сказал, что в выражении типа (a/b+x)*y, где a и b -целые, это самое a/b в любом случае тоже будет целым.
Это действительно так?

Почему считается что железо надо программить на Сях? На мой взгляд эффективней и понятней асма ничего не придумано. А для всех остальных задач наиболее оптимален OP. Что касается Ся - не вижу никаких преимуществ языка. А может это я не вижу?

Ch>Для меня Паскаль - это известный мне уже почти тридцать лет язык (я имею в виду, начиная с Алгола).

Николай Валерьевич, Паскаль - не есть Алгол, принципиально. То, что синтаксис похож - совсем не означает, что это один и тот же язык.

Ch>Я умею выражать на нём свои мысли и понимаю программы, написанные на нём.

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

Ch>Программы, которые я пишу, делают то, что я хочу. Всегда.
Ch>На фиг мне сдались все остальные языки?

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

Нельзя объять необъятное (с)

Ch>Да я лучше ЭВМ сделаю, которая будет понимать меня, то есть Паскаль. Слава Богу, возможности есть... . Злоупотребление служебным положением, понимаешь...

Именно злоупотребление, без шуток.

Наталья>Как-то глядя в код ОП С++-программист сказал, что в выражении типа (a/b+x)*y, где a и b -целые, это самое a/b в любом случае тоже будет целым.
Наталья>Это действительно так?

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

Наталья>Как-то глядя в код ОП С++-программист сказал, что в выражении типа (a/b+x)*y, где a и b -целые, это самое a/b в любом случае тоже будет целым.
Наталья>Это действительно так?

Да ничего подобного.
Всё зависит от того, переменной какого типа присваивается значение указанного Вами выражения. Если эта "окончательная" переменная имеет один из типов с плавающей точкой, то всё будет рассчитано правильно. При трансляции программы будет создана невидимая программисту промежуточная переменная того же плавающего типа, что и "окончательная". В процессе вычислений этой промежуточной переменной будет присвоено значение a/b (с точностью, определяемой типом).
Если эта "окончательная" переменная имеет один из целых типов, то будет диагностирована СИНТАКСИЧЕСКАЯ ошибка ещё при трансляции программы. Для того, чтобы результат a/b имел целый тип, и не было синтаксической ошибки, нужно использовать оператор div (деление нацело) a div b.
Процедура контроля правильности применения типов ещё на этапе трансляции - это один из фильтров ошибок, которыми Паскаль защищает программиста от недомыслия.

MABP>1. OP - ЯВУ, С++ - макроасм. переросток.

Так же, как OP - обучалка-переросток

MABP>2. На ОР нужно приложить дополнительные усилия, чтобы сделать программу менее надежной, на С++ наоборот.

С этим не спорю. Но это только одна из сторон.

MABP>3. Читабельность исходников на ОР выше, т.е. надо прилагать меньше усилий для этого.

Читабельность программы прямо пропорциональна степени владения языком и(!) компактности исходного кода. Синтаксис Си, а тем более Си++ позволяет писать более информационно насыщенные программы, и как следствие, психофизиологически более удобочитаемы, чем OP. Естественно, для того, кто хорошо владеет языком.

Поясню.

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

Скажем, a:=a+1; и a:=a-1; с точки зрения подсознания намного ближе друг к другу, чем a++; и a--;

С этой же точки зрения "скобки" begin ... end хуже подходят для выделения блоков, т.к. они разной длины и субъективно некомплиментарны, по сравнению с { .. } - не говоря уже о том только, что чисто энергетических затрат (на перемещение глазного яблока, обработку и передачу данных на сетчатке) фигурные скобочки выгоднее.

Естественно, если подсознанию лучше знаком синтаксис OP, то оно будет воспринимать программы на OP как более понятные и грамотные, чем на C++. Но при равном опыте работы C++ будет гораздо читабельнее.

Хотя и это всё "от лукаваго", т.к. с точки зрения подсознания и C++ далеко не идеален.

MABP>4. ОР не уступает С++ в скорости выполнения и объему кода.

Так говорить нельзя. Нужно сравнивать конкретные компиляторы. И если про другие платформы не скажу - не знаю, то под Wintel среди "Паскалей", компиляторов равных MSVC++ и Watcom C++ нет. Только слышал, что какая-то из реализаций Оберона на этом уровне в плане простых выражений, но проигрывает на объектах и контроле типов.

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

Это очень спорный вопрос.

Если под что-то ускоспециализированное, то это бесспорно.
Если речь идёт о компактности конечного когда - то да, если не брать в расчёт Forth (или вообще языки с байт-кодом - те же Java и Basic).

Если быстродействие - то на Wintel архитектуре C давно уже генерит более эффективный код при грамотном написании. Ты просто не в состоянии учесть всех тонкостей взаимодействия тайминга команд на конвейерах. Уже на простом Pentium это было очень сложно делать. Я тогда ещё программил на асме, так вот, я некоторые хитрости по оптимизации вытаскивал из кода, генерируемого MSVC++ 4.x

Про надёжность, скорость написания и удобочитаемость асмовского текста - я лучше промолчу

TEvg>А для всех остальных задач наиболее оптимален OP. Что касается Ся - не вижу никаких преимуществ языка. А может это я не вижу?

Если считать в духе "что такого можно сделать на Си, чего нельзя на Паскале" (и наоборот) - то языки совершенно эквивалентны. Ни один не лучше другого. Если брать читабельность программ - то я об этом много написал в предыдущем топике. Если брать скорость написания - она прямо пропорциональна читабельности программ и обратно пропорциональна объёму вводимого кода - по обеим параметрам C++ удобнее. Я уже молчу о таких мелочах, как описание переменных по мере их использования (за отсутствие такой возможности очень не люблю Паскаль). Кстати, не стоит умалчивать и о реализациях - сколько там типов строк в Delphi? А как не перепутать, какой тип где использовать? Ну т.д.

Наталья>>Как-то глядя в код ОП С++-программист сказал, что в выражении типа (a/b+x)*y, где a и b -целые, это самое a/b в любом случае тоже будет целым.
Наталья>>Это действительно так?

Ch>Да ничего подобного.
Ch>Всё зависит от того, переменной какого типа присваивается значение указанного Вами выражения. Если эта "окончательная" переменная имеет один из типов с плавающей точкой, то всё будет рассчитано правильно.

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


Ch>При трансляции программы будет создана невидимая программисту

Очень замечательно - невидимая программисту, такого можно понаделать...

Ch>В процессе вычислений этой промежуточной переменной будет присвоено значение a/b (с точностью, определяемой типом).

хорошо, выражение типа z*(x +y * (a/b - c/d)) - в какой момент переведут в плавающие переменные c и d?

Ch>Если эта "окончательная" переменная имеет один из целых типов, то будет диагностирована СИНТАКСИЧЕСКАЯ ошибка ещё при трансляции программы.

В С/С++ - это не ошибка, это нормальная программная конструкция, с детерминированным поведением.

Ch>Процедура контроля правильности применения типов ещё на этапе трансляции - это один из фильтров ошибок, которыми Паскаль защищает программиста от недомыслия.

Ну так в какой момент произойдет приведение типов?
Это к вопосу о ясности поведения программы из текста.
По уму нужно написать float(a)/float(b), в этом случае можете быть уверены, что вычисления будут с плавающей точкой а не как компилятроу прививделось...

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

Во!
Эти слова надо распечатать и повесить на стену!
Впрочем, мне это не к чему.
Слава Богу, начальство у нас понимающее
Когда я им (а у нас тоже занимаются железом) рассказал про удобство Форта, то они вполне предположили, что следующий проект можно начать на нём. Но потом, по здравому размышлению, отказались. Причина, правда, та же, по которой у нас ну никак не покатит Паскаль - все программы тестирования моделей у нас рассчитаны на C++. А без этого никак. Собственно, тестирование - это 99.9% всей нашей работы.

Наталья>Это действительно так?
Владимир Малюх>Ну будут, а что тут такого? Вполне определенная операция, заранее известно что будет комп делать.

Кстати, более того - в новых ЯВУ имеется тенденция избавления от типизации переменных, как таковой. То есть, это давно уже возникало, но сейчас в PHP, Perl и JavaScript это укоренилось очень плотно. Я вначале тихо матерился, а сейчас проникся Для прикладного программирования невероятно удобно.

Кстати, забавно, если в PHP или JavaScript типизация отсутствует как класс, то в Perl она есть, но относится к типизации Си или Паскаля как английские падежи к русским Есть три типа переменных - скалярная (простая), массив (с числовым индексом, обычным) и хэш (ассоциативный массив - символьный индекс).

Наталья>>Это действительно так?
Ch>Да ничего подобного.

Да ничего подобного

Ch>Всё зависит от того, переменной какого типа присваивается значение указанного Вами выражения.

Компилятор Си не делает работу за программиста!
Кстати, вот и доверяй после этого Паскалю - он выполняет неявные для программиста вещи!
Присваивание - это обычный оператор, один из аргументов которого - выражение справа. И к какому типу его приводить - он не знает и знать не должен! Он тупо рассматривает выражение в порядке приоритетов выполнения. В данном случае, сперва a будет делиться на b. Оба аргумента целочисленные. Так что и результат будет целочисленный. Потом к нему прибавляется c (с плавающей точкой), так что сложение будет проистекать уже в формате с плавающей точкой. И результат будет соответствующий.

void main(void)
{
int a=2;
int b=3;
float c=1.0;
printf("%f",a/b+c);
}

В итоге на экране 1.000000;


Ch>При трансляции программы будет создана невидимая программисту промежуточная переменная того же плавающего типа, что и "окончательная". В процессе вычислений этой промежуточной переменной будет присвоено значение a/b (с точностью, определяемой типом).

Предсказуемый компилятор, претендующий на звание надёжного НЕ ДОЛЖЕН оперировать какими-то скрытыми переменными и выполнять неявные операции.

Ch>Процедура контроля правильности применения типов ещё на этапе трансляции - это один из фильтров ошибок, которыми Паскаль защищает программиста от недомыслия.

В таком случае куда лучше смотрится Forth.
Там вообще (в классическом случае, т.к. извращения возможны разные) целые числа и числа с плавающей точкой лежат в разных стеках и обрабатываются разными операторами. По стандарту + - для целых чисел (D+ для чисел двойной точности), F+ - для чисел с плавающей точкой. Ну и аналогично уже часто добавляют S+ или $+ для строк, A+ для массивов и т.д.

Hi!

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

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

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

TEvg> А для всех остальных задач наиболее оптимален OP. Что касается Ся - не вижу никаких преимуществ языка.

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

А раз уж мы на авиационном сайте - ему нужна ОНА. В смысле Ада, конечно . Afaik, Ил-96 летает именно на Аде. Любителям Паскаля на него морально легче будет перейти.

2 Наталья :

Деление целого на целое дает целое, с отсечением дробной части.
Но смысл жизни не в этом

Hi!

>>Будете состязаться со мной в скорости кодирования? Я на сях, Вы на асме. Не советую - Вам только по клаве насколько больше стучать.
TEvg>Железо лучше программить на асме! Отладка в 1000 раз легче, ведь все работает так как программер написал, а не как компилятор.

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

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

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

TEvg>Для меня все наоборот. Помню как я разбирал железный софт на сях - бррр..

Это от незнания языка, нормальное дело.

Вообще, если уж на то пошло, то работать с железом лучше на VBA Берутся стандартные железки с уже написанными драйверами - и в чем-то типа LabView или GeniDAQ, мышкой.

>Вообще, если уж на то пошло, то работать с железом лучше на VBA
>Берутся стандартные железки с уже написанными драйверами
Какой VBA??? Какие стандартные железки? Какие дрова? Речь идет о самом нижнем уровне - написание VxD к примеру. А железка зачастую сделана дядей Васей с паяльником.
А все что повыше дров - на OP.

TEvg>Это для вас. Для меня begin end удобнее чем {}, а i:=i+1; удобнее чем i++

Вам виднее, только не говрите, что кнопок нужно нажать меньше для begin-end, чем для {}. А нажатий этих за годы работы -миллионы.

>>Кстати, не стоит умалчивать и о реализациях - сколько там типов строк в Delphi?
TEvg>Ой много! shortstring, string, widestring, PChar.. да все и не упомнишь. Это конечно не есть хорошо, но вообще паскалевская строка для меня удобнее чем сишная с нулем.

Ну да, для вас..

>quote:

---

TEvg>void main(void)
TEvg>{
TEvg> int a=2;
TEvg> int b=3;
TEvg> float c=1.0;
TEvg> printf("%f",a/b+c);
TEvg>}

---

 

>За что мне Ся и не понравилась.

TEvg>куда лучше:

TEvg>var a,b:byte;c:double;
TEvg>begin
TEvg>a:=2;
TEvg>b:=3;
TEvg>c:=1.0;
TEvg>write(a/b+c);
TEvg>end.

Вы не поняли про что мы вам говорим. Рома вам наглядно показал, что там где Ch ожидает получить 1.5 он получит 1.0.

>>Предсказуемый компилятор, претендующий на звание надёжного НЕ ДОЛЖЕН оперировать какими-то скрытыми переменными и выполнять неявные операции.

TEvg>Может быть, но компилятор OP действительно надежен.

Это -реализация, вам же Роман совсем про другое говрил. Текст исходного кода должен интпретироваться читателем/писателем этого кода однозначно.

>>А сишный - даже студенческие поделки вполне читаются.
TEvg>Для меня все наоборот. Помню как я разбирал железный софт на сях - бррр..

Может в вас или в конкретном коде дело? А насчет асма - я с любопытсвом посмотрю как вы напишете полноценный драйвер для GeForce 3 целиком на asm, реализация OpenGL -обязательная в полном объеме - дерзайте! неужели непонятно, что есть еще и такая вещь как объем проекта?

>Вам виднее, только не говрите, что кнопок нужно нажать меньше для begin-end, чем для {}.
Не буду.

>Ну да, для вас..
Ага. Для меня.

>Это -реализация, вам же Роман совсем про другое говрил. Текст исходного кода должен интпретироваться читателем/писателем этого кода однозначно.
А чо? какие сложности?

>Может в вас или в конкретном коде дело? А насчет асма - я с любопытсвом посмотрю как вы напишете полноценный драйвер для GeForce 3 целиком на asm, реализация OpenGL -обязательная в полном объеме - дерзайте! неужели непонятно, что есть еще и такая вещь как объем проекта?
Ха Ха. А вы чтоль их на сях писали? Драйвер мыши или VGA/VESA или плоттера или сверлильного станка - на асме пишутся запросто.

TEvg>Это для вас. Для меня begin end удобнее чем {}, а i:=i+1; удобнее чем i++

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

TEvg>Удобно на первый взгляд. Я когда пересел с басика на Паскаль жутко ругал за описание переменных язык и товарища Вирта и его родственников.

Я не про описание переменных вообще - это обязательно.
Но вот описание переменных в шапке программы - атавизм, усложняющий написание програмы. Компилятору всё равно, где её объявят, а вот мне скакать вверх/вниз по программе в несколько экранов как-то не по душе

TEvg>Но потом понял что это удобно, особенно в больших или чужих программах.

Это не просто удобно, а жизненно необходимо и не только в больших, но и в маленьких программах.
В том же Perl, опционально можно писать и так и эдак, но я даже в тестовых программках на полтора десятка строк всегда пишу use strict; - проще лишний раз описать переменную, чем потом выискивать опечатки в именах переменных. И на VB я всегда использовал option explicit (или как оно там пишется - уж сколько лет не писал).

TEvg>Ой много! shortstring, string, widestring, PChar.. да все и не упомнишь. Это конечно не есть хорошо, но вообще паскалевская строка для меня удобнее чем сишная с нулем.

Какая там длина максимальная у дефолтовой паскалевской строки?

TEvg>Хе.. асм - язык совершенно свободный от типизации

Да ну! Начиная с того, что на x86 нет ни одной пары одинаковых регистров, кроме FS и GS (исключая, конечно, сопроцессор, MMX и SSE), так ещё и типов данных от BYTE до TWORD одних только базовых... Да ещё всё это ручками ворочать... Кошмар

>> printf("%f",a/b+c);
>За что мне Ся и не понравилась.

Между прочим всё очень логично и наглядно.
Ни одной неявной операции.

TEvg>write(a/b+c);
TEvg>Может быть, но компилятор OP действительно надежен.

Но непредсказуем

TEvg>Железо лучше программить на асме! Отладка в 1000 раз легче, ведь все работает так как программер написал, а не как компилятор.

Железо лучше программировать на Форте. По отладке ему тут и близко никто не лежал. Форт для таких целей - сам себе ОС. А для отладки на любых тругих языках для любой простейшей операции требуется цикл редактирование/компиляция/запуск/анализ (на Форте прямо - операция/результат)

TEvg>Для меня все наоборот. Помню как я разбирал железный софт на сях - бррр..

Значит так код писали.
Если не соблюдать культуру программирования, то программы на чём угодно будут ужасно читаться. Ну, может, Phyton некоторое исключение из ряда, но я его почти не знаю.

Hi!

>>Берутся стандартные железки с уже написанными драйверами
TEvg>Какой VBA??? Какие стандартные железки? Какие дрова? Речь идет о самом нижнем уровне - написание VxD к примеру. А железка зачастую сделана дядей Васей с паяльником.

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

=KRoN=>Железо лучше программировать на Форте. По отладке ему тут и близко никто не лежал.

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

>>Это -реализация, вам же Роман совсем про другое говрил. Текст исходного кода должен интпретироваться читателем/писателем этого кода однозначно.
TEvg> А чо? какие сложности?

выше было показано, что значение переменной y после исполнения выражения y = x*(a/b +c), где y - плавающее, а a и b целые - не всем неочевиден при чтении текста.

>>Может в вас или в конкретном коде дело? А насчет асма - я с любопытсвом посмотрю как вы напишете полноценный драйвер для GeForce 3 целиком на asm, реализация OpenGL -обязательная в полном объеме - дерзайте! неужели непонятно, что есть еще и такая вещь как объем проекта?

TEvg>Ха Ха. А вы чтоль их на сях писали?

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

TEvg>Драйвер мыши или VGA/VESA или плоттера или сверлильного станка - на асме пишутся запросто.

Мышь "немного" проще чем GF3, в этом и загвоздка знаете ли.