Паскаль и С++ - различные понимания свободы?

← →
Ермак © (2005-11-24 13:47) [0]

Доброго времени суток всем!

Сегодня на кафедре произошел у меня спор с убежденным приверженцем С++ (Его девиз: "Искореним дух Паскаля из наших стен!").
Мне был поставлен провокационный вопрос - какие языки я считаю неудачными? - на который был получен вполне ожидаемый ответ. Далее - все по стандартной схеме... Но разговор натолкнул на интересные размышления, которыми решил поделиться. Мыли даже больше философские.

Далее мне был выдвинут стандартный набор тезисов (весь мир пишет на С++, а в бизнесе побеждает естественный отбор; скорость паскалевских-обероновских программ ниже; можно ли написать драйвер на Обероне), на что я ответил так же стандартно (во-первых, привычка; для особо критичных проектов выбирается всегда не С++;.NET вообще тяготеет к паскалевким концепциям с с-шным синтаксисом; миф про скорость приказал долго жить уже давно, на Обероне написаны целые ОС, а не только драйвера). Но эти тезисы моего оппонента были не главными. Главный тезис звучал так: Паскаль ограничивает свободу программиста. Поэтому он плох и должен исчезнуть, безусловно и окончательно.

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

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

Однако вопрос в нашем споре был поставлен, в конечном счете, так: запрет делать ошибки - это хорошо или плохо? Ведь это ограничивает личную свободу программиста! Не правда ли, пришли уже к философии? Это, кстати, во многом объясняет ожесточенность дискуссий по поводу того, какой язык программирования лучше. Но особого накала эти дискуссии достигают при обсуждении вопроса: какому языку учить?

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

Возвращаясь к обучению: учить плавать "в воде, а не земле" - это значит учить решать задачи, приближенные к тем, с которыми придется столкнуться в индустрии. И хороший язык программирования (избавленный от "жестокой" якобы "реальности" С++) подобен здесь не земле вместо воды, а тренеру, который страхует от ошибок и прививает правильный стиль. А, как известно, в профессиональном спорте самоучкам делать нечего - тренер просто необходим. Если хорошо подготовленному программисту понадобиться перейти на С++, он сделает это легко и так же легко справится с его сложностями (говорю по собственному опыту) - просто будет писать программы в уже привычном хорошем стиле, избегая неграмотных или опасных трюков. Хотя эффективность разработки все равно будет ниже, т.к. больше внимания будет уходить на слежение за правильностью работы инструмента.

Возвращаясь к общему вопросу свободы: абсолютной свободы-то нет нигде... Если следовать логике моего оппонента, то перила на корабле плохи, так как ограничивают свободу человека упасть за борт. Крышки на розетках и изоляция на проводах также излишни. А зачем? Свободы-то больше! Представьте: никаких удлинителей не нужно, накинул концы на провода в любом месте, и готово. А насчет опасности вывалиться за борт или погибнуть от электрошока - так надо быть сверхвнимательным! Только много ли у нас останется внимания и времени на все остальные, не в пример более важные стороны нашей жизни, если мы все время будем думать о том, как бы не перейти через опасную черту, с которой снято ограждение...

Знание всегда приносит с собой несвободу. Наиболее несвободен тот, кто ничего не знает об опасностях. Так же и в программировании: новички - самые свободные, они иногда пишут такое, что диву даешься, сколько бредовых комбинаций можно собрать из ограниченного набора ключевых слов... Программист-профессионал, на чем бы он не писал, ограничивает себя точно так же, как если бы он писал на самом строгом языке. Если нет внешних ограничений, приходится выставлять самоограничения. Но от усталости, временного ослабления внимания, наконец, от простой опечатки не застрахован никто, так же, как и от выпадания за борт на корабле без перил... А последствия ошибки в программе могут быть гораздо более серьезными, если это, например, система управления особо критичными объектами. Вот и пишут такие системы не на С++, а на Modula или Ada, и никто не спорит с ограничением свободы, т.к. понимают - ошибаться здесь нельзя.

Возвращаясь к общему пониманию свободы: сплошь и рядом можно услышать, что запреты ставить нельзя, так как человек будет несвободен. Иногда можно услышать дополнение: несвободен в своем творчестве. Оно содержит в себе важную мысль: одним из следствий (истинной) свободы является творчество. Так давайте использовать этот критерий! Дает ли снятие запрета на опасные ошибки новую степень свободы для творчества? Ничего подобного... Что в программировании, что в печатном слове это ведет лишь к тому, что каждый "творчески" наступает на все новые грабли, по которым до него прошли уже тысячи таких же искателей "свободы творчества". А результат "творчества" - нулевой. Полное бесплодие.

← →
Думкин © (2005-11-24 13:55) [1]

> Ермак © (24.11.05 13:47)

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

← →
TUser © (2005-11-24 14:16) [2]

По всей видимости инструкции, типа вот этой
for (i=+a=-b+4;i<a+b++;i=b--);
есть жуть какая необходимая в жизни штукенция.

← →
ANB © (2005-11-24 14:22) [3]

a+++b.

← →
data © (2005-11-24 14:36) [4]

я тоже работаю в среде ненавистников паскаля :) переучилась на С++

← →
alex_*** © (2005-11-24 14:44) [5]

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

← →
isasa © (2005-11-24 14:59) [6]

TUser © (24.11.05 14:16) [2]
ANB © (24.11.05 14:22) [3]

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

← →
umbra © (2005-11-24 15:06) [7]

2 isasa © (24.11.05 14:59) [6]

так зато свободы - завались!

← →
ANB © (2005-11-24 15:11) [8]

Да ладно. Все языки нормальные. И у каждого есть свои минусы.

← →
TUser © (2005-11-24 15:15) [9]

> isasa © (24.11.05 14:59) [6]

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

← →
wicked © (2005-11-24 15:18) [10]

как надоели пасквилянты (не побоюсь этого слова), не знающие языка, но пробующие доказать всем остальным, как же они бедняжечки ошибаются, что используют его.... попытаюсь показать, что это не так......
1) сравнивать паскаль и си++ - некорректно..... паскаль и си - да, но это структурные языки, имеющие минимум различий и для большинства задач равноценные.... отличия провляются только вследствие происхождения языка: паскаль - язык "от теории", си - изначально заменитель ассемблера...... оттуда же, кстати, и растут ноги и у препроцессора, и у операций с побочным эффектом.....
2) сравнение обьектного паскаля с си++ опять таки нам мало что даст, так как каждый разработчик ООП языка формирует реализацию этого ООП по своему, в результате чего каждый язык имеет свои премущества, наглядно показывающие то, о чем думали разработчики при проектировании..... и тот, и другой позволяют как наломать дров, так и сделать красивую элегантную вещь....
но в силу своей бесхребетности си-образные языки просто навязывают необходимость более глубокого обдумывания архитектуры программы или библиотеки, дабы не погрязнуть в ненужных мелочах.... вот и всё.......

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

Dixi.

← →
Ермак © (2005-11-24 15:20) [11]

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

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

Ну и насчет задач: область применимости одинаковая. Я ведь имею в виду не Паскаль 70-х, а современный Object, или Оберон.

← →
wicked © (2005-11-24 15:25) [12]

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

"не спорь с дураком - посторонние могут не увидеть разницу между вами" (цы)

← →
Lamer@fools.ua © (2005-11-24 15:26) [13]

>>ANB © (24.11.05 15:11) [8]

>Да ладно. Все языки нормальные. И у каждого есть свои минусы.
Не-а. У Паскаля, например, нет ни плюсов, ни минусов. Зато у C++ — только плюсы, причём в количестве двух штук.
:o)

← →
TUser © (2005-11-24 15:28) [14]

> Lamer@fools.ua © (24.11.05 15:26) [13]

А еще есть специальный язык Си минус минус.

← →
Ермак © (2005-11-24 15:35) [15]

>изучать рекомендуется, кстати, и паскаль, и си.... иначе человек всю жизнь >будет думать, что сишники (паскалисты) - бедные обделенные люди.....

Согласен. Знаю ++ очень хорошо (именно поэтому вернулся на Паскаль :-)
Но учить все равно надо начинать с более строгого. Лучше сразу объяснить, чего делать нельзя, а уже потом, когда понадобиться, научить, как этот запрет обходить. Помню, когда только начинал писать, я никогда не применял Chr и Ord - а вот только byte() и char(), чтоб только назло языку нарушить типизацию :-)

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

← →
Igorek © (2005-11-24 15:43) [16]

> почему спор о языках превращается в холли вар

Да потому, что язык - это часто предмет веры.

← →
Тульский © (2005-11-24 15:48) [17]

Ну и подскажите нормальную (не глючную) среду разработки на C++. Для Windows.

← →
KodV © (2005-11-24 16:00) [18]

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

← →
TUser © (2005-11-24 16:06) [19]

> Тульский © (24.11.05 15:48) [17]

FAR + colorer :)

← →
alex_*** © (2005-11-24 16:15) [20]

как слышал здесь фразу: "тебе шашечки или поехать". Вот как раз к этому. Вам задачи решать или свободой/несвободой наслаждаться? я писал и на С++ и Delphi нравится и то и это. А писать буду на том, за что будут деньги платить. На VB, пожалуй, таки не буду :)
[17] - подскажи до кучи безглючную среду программирования для Дельфи. Для Windows.

← →
Ермак © (2005-11-24 16:21) [21]

>Ну и подскажите нормальную (не глючную) среду разработки на C++. Для >Windows.

Пожалуй, доверять можно только Microsoft. Однако компилятор не полностью поддерживает стандарт (в работе с шаблонами, например). Но это кредо МС - класть на все стандарты и вводить свои :-)

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

Да и полной поддержки стандарта (тем более, что тот обновляется часто) я не встречал. Это сказывается в работе с шаблонами. А без шаблонов теряется весь смысл С++ - это действительно отличная вещь, которая там есть. Такую же поддержку обобщенного программирования я видел только в Ada-95.

← →
Тульский © (2005-11-24 16:57) [22]

> [17] - подскажи до кучи безглючную среду программирования
> для Дельфи. Для Windows.

Дельфи глючна гораздо в меньшей степени, чем C++ Builder. Помучился я с ней в свое время и решил отказаться.

← →
alex_*** © (2005-11-24 17:02) [23]

на МС переходи. Там глюков вроде меньше. D2005 и выше не смотрел, правда

← →
Юрий Зотов © (2005-11-24 17:43) [24]

> Ермак

Я бы привел оппоненту такой довод.

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

И вот доказательство НЕограничения свободы:

type
PWord = ^word;
var
I: integer;
W: word;
begin
...
W := PWord(Integer(@I) + 2)^;
end;

А вот доказательство того, что очень плохо, когда свобода программисту дается без всяких оговорок (пример из моей собственной реальной практики, язык PL/1, в котором программисту действительно давалась абсолютно полная свобода и без всяких оговорок):

DCL I DEC FIXED(1);
// Это объявление целой переменной I c диапазоном значений -9..9

DO I=0 TO 9 // Это цикл со счетчиком от 0 до 9 и шагом 1
... // Здесь тело цикла

Вопрос к уважаемому оппоненту - пусть он найдет в этом простейшем коде ошибку. Потом пусть подумает, что когда ошибочная строка находится среди многих тысяч других, то вычислить ее совсем непросто (когда-то у меня ушло на это 3 дня). А потом пусть подумает, что если бы этот код был написан на Паскале (не на Delphi, а именно на Паскале, в Delphi многое уже не совсем так), то ошибку и искать бы не пришлось - на нее бы ругнулся уже компилятор, притом с точной диагностикой.

← →
jack128 © (2005-11-24 17:51) [25]

Юрий Зотов © (24.11.05 17:43) [24]
DCL I DEC FIXED(1);
// Это объявление целой переменной I c диапазоном значений -9..9
Гы. Меня уже радует этот язык. Это типа объявление переменной с одним значащим десятичным знаком?? (dec fixed(1)) Так что ли??

← →
isasa © (2005-11-24 17:53) [26]

А я не любил с DEC FIXED работать, BIN FIXED.

PS Выход из цикла I=10 DEC FIXED(2). Ет вы так память экономили?

← →
Sandman29 © (2005-11-24 17:56) [27]

DO I=0 TO 9 // Это цикл со счетчиком от 0 до 9 и шагом 1

После 9 I принимает значение -1 и поэтому всегда выполняется условие цикла (I <= 9)?

← →
Sandman29 © (2005-11-24 17:56) [28]

то есть -9 :)

> Юрий Зотов © (24.11.05 17:43) [24]

> W := PWord(Integer(@I) + 2)^;

Я считаю, что это неверно. Чем гарантировано, что при преобразовании к Integer не произойдет потери разрядности адреса? На 64-битках не пробовали этот "фокус"?

Уж если и делать, то так:

W := PWord(pchar(@I) + 2)^;

про языки и их похожесть:
вчера плотнее взялся за Java, оказалось, что C# и J2ME - близнецы-братья по синтаксису!!!

> Sandman29 © (24.11.05 17:56) [28]
> isasa © (24.11.05 18:05) [29]

У меня возникло зацикливание (и понятно, почему).

> Verg © (24.11.05 18:10) [30]

> Чем гарантировано, что при преобразовании к Integer не произойдет
> потери разрядности адреса?

Тем, что на 32-битной платформе адрес I гарантированно будет ниже 2-х Гб. А на 64-битной (если она организована по тем же принципам) он будет гарантированно ниже половины адресного пространства - значит, Integer все равно прокатит нормально (поскольку он generic - то есть, тоже 64-битный).

WondeRu © (24.11.05 18:18) [31]
C# и J2ME - близнецы-братья по синтаксису

C# - это просто правильный Java (c) чего-то из RSDN Magazine

> Тем, что на 32-битной платформе адрес I гарантированно будет
> ниже 2-х Гб.

Это ты про Win32 или вообще про любую 32-х разрядную платформу?

Поинтерам - арифметику поинтеров! (типа лозунг ) :))

Пусть компилер сам думает про платформы и разрядности, если уж допускает арифметику с поинтерами.

Это из той же оперы, что и задача о получении максимального адреса ВАП в одно действие.

> Поинтерам - арифметику поинтеров! (типа лозунг ) :))

Поинтеры -- фтопку! (типа, тоже лозунг)

← →
iZEN_ (2005-11-24 20:48) [37]

> Kerk © (24.11.05 18:22) [33]
>
> WondeRu © (24.11.05 18:18) [31]
> C# и J2ME - близнецы-братья по синтаксису
>
> C# - это просто правильный Java (c) чего-то из RSDN Magazine

:))
В C# нету Checked Exceptions, то есть словить чужое исключение без обращения к справке - не проблема. C# - это те же грабли (C++): вид сбоку.

Введение ключевого слова throws в сигнатуру метода позволяет большую часть "человеческих" ошибок на этапе компиляции. Но в C# от этого сознательно отказались, подставив под удар ВНИМАТЕЛЬНОСТЬ программиста.
Не приняв во внимание субсистему восстановления и поддержки живучести, язык C# во многом повторяет путь своего небезопасного предшественника C++.

Язык Java пошёл по пути контрактного программирования, указанного Бертраном Мейером в языке Eiffel-88 (кстати, Джеймс Гослинг, создатель Java, назвал Eiffel образцом безопасного языка. Ada, кстати, тоже отдыхает). Поэтому Java более безопасен чем C#.

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

недавно нашол ошибку в программе на С++ (не своей ;), а дело было так,
начал связку делать с одним ком обьектом который наши С-шники для 1С-ников делали, но вот понадобилось и мне с ним работать (может скоро замену 1С-у напишу ;о))), и сразу фигня началась, там по идее обьект через вариант возвращается или NULL при ошибке(нет устройства), т.е. нужно обрабатывать и реагировать, а оно на проверке VarIsNull через раз "слетает"... проверил несколько раз выяснил что в можно проверять через приведение к диспач и сравнение с nil но тут уж "вылеты" в обратных, в тех что раньше были нормальными условиях, или с помощью VarIsClear, здесь всегда работало...
в принципе решил, но все одно пошол к автору обьекта, типа "чтото у тебя тут не то с возвращаемыми значениями". тот проверил, действительно он там гдето просто ноль возвращает, несмотря на то что нужно вариант (а вариантный ноль это не совсем ноль ;), это структура с указанным типом и значением в ней равном нулю), и при том тип указанный у функции стоит интерфейс.

а тоже спорили, жосткое типизирование не дает удобств, больше писать приходится (это когда обьяснил, что если нужно то явно можно и слона к мухе преобразовать. но тогда запись показалась слишком длинной).
а самый прикол в том, что эту ошибку они уже месяц искали, и уже готовились на "глюкавость" 1С-а списать, нерешаемую... ;) и там и там типы как хочеш преобразуются, то что неверное значение получил он(1С) сразу не смотрит (как и С при отправке, неважно что тип интерфейс, ноль (интеджер) присваивается за милую душу), глюк происходит не сразу, а после при обрашении к устройству (оно в этом виде в 1С определялось как существующее), и сразу AV вместо сразу и только "несоответствие типа. не могу преобразовать" в дельфи, и не прямо на месте а уже в дебрях кода при не раз переданном значении... чудеса прямо. вот работает, а вот нет, и ничего не меняли. ;)
вот. два языка со "свободой типов"... а чтобы найти глюк надо третий, который ее ограничивает.

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

Странный вы народ, ей-богу. Какая разница, на каком языке писать плохие программы ?

> Игорь Шевченко © (24.11.05 21:47) [39]
> Странный вы народ, ей-богу. Какая разница, на каком языке
> писать плохие программы ?

Не скажи. На одном из языков плохие программы получаются намного лучче.
А на другом хорошие - намного хуже. Доказано занудством.

Паскаль и С++ - различные понимания свободы? Найти похожие ветки