Про языки программирования

Booster

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

scf

Можно поподробнее, что Вы имеете в виду, какие такие механизмы управления временем жизни объектов Вам нужны и вам указатели Паскаля мешают работе с динамическими массивами?

Что же касается минусов для меня, то для меня основные минусы в Си/Си++, причём настолько сильные, что полностью перечёркивают абсолютно все достоинства, -- это паршивый контроль типов (который даже в Си++ далёк от должной строгости), а главное -- многочисленные возможности допустить случайные ошибки-опечатки, приводящие к неверной работе программы, а не к синтаксической ошибке и соответствующему сообщению компилятора. Это возможность написать = вместо == и наоборот, & вместо && и наоборот, и т.д.

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

Обязательное объявление переменных в начале процедуры -- ИМХО, достоинство, а не недостаток. Дисциплинирует, знаете ли, заставляет думать, как будет процедура работать в целом, а не писать её как попало, объявляя где попало эти самые переменные.

Clerk

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

_proteus

Потому что в своё время Борланд и Мелкософт договорились о разделе "сфер влияния". Достоинства-недостатки языков тут никакой роли не играют.

 

Как истовый программист на Delphi, хочу сказать несколько слов в защиту языка и платформы:
В последние годы мне приходится разрабатывать финансовые приложения, с достаточно высокой ценой ошибок. Так вот, я сохраняю уверенность, что код на Delphi гораздо более приближен к английскому языку, а значит обладает гораздо большей читабельностью, и как следствие ошибки в нем более заметны, чем машинно-ориентированном синтаксисе Це. Что касается лаконичности языка Це, то это очевидно импонирует программиса, которым надо набивать по мегабайту рутинного кода в день, а всем остальным это должно быть по фигу - главное научится слепой печати. Особенно меня радует, когда мегалаконичное Це выражение, из нагромождений операторов [>> & % ~] сравнивается с несколькими строками на Дельфи - на автомате такое выражение написать не всегда просто, так что я не понимаю где собственно экономия времени и усилий? Или мегабайты на жестких дисках стали дефицитом.

Даже вот такие вещи, как операторы присвоения и сравнения, в Delphi обозначаются как ":=" и "=", а в Це соответственно "=" и "==", требуют от программиста чуточку больше внимания, и меньше внимания со стороны компилятора, что есть нехорошо. Бороться с этим программисту Це предлагается закалкой внимания, и кривовастыми методами, вроде ставить константу в сравнении первой. Вовсе внимание не обращается, что задачи порой приходится решать в цейтноте, в 24-часовой рабочий день, а значит внимательность может упасть, и ошибки начнут проникать в код толпами.

 

_basmp_

Вкупе с трактовкой присваивания как оператора, а не операции, а также наличием полноценного логического типа, несовместимого по присваиванию с числовыми типами, это является как раз достоинством. Например, в Си/Си++ легко сделать ошибку вроде a = b = c вместо a = b == c. Компилятор обе конструкции благополучно проглотит, поскольку они совершенно корректны синтаксически, ну а лёгкость ошибки заключается в использовании одного и того же знака для их обозначения (случайно нажать лишний раз = или нажать его два раза вместо одного довольно просто). В Паскале такое, понятное дело, невозможно: компилятор пошлёт сразу же.

Partner

Добавлю: зато значительно надёжнее. Как и многие другие вещи.

keYMax

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

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

Кстати, а при программировании на любом другом языке что, не требуется знать необходимые компоненты-классы-шаблоны или просто библиотечные функции?

Что за дирик, не знаю, а вот мнить себя "крутым кодером" -- всегда глупо. И очень часто свойственно как раз посредственностям. Ничего личного -- но Сократ знал, что ничего не знает.

 

SII

Автоматический вызов деструкторов как в плюсах или сборка мусора как в яве.
Пример:

Код (Text):

1. a := ClassA.Create;
2. b := ClassB.Create;
3. c := ClassC.Create;
4. .....
5. a.Free;
6. b.Free;
7. c.Free;

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

Код (Text):

1. auto_ptr<ClassA> a(new ClassA());
2. auto_ptr<ClassB> b(new ClassB());
3. auto_ptr<ClassC> c(new ClassC());

Хорошая программа на С++ не должна содержать ни одного вызова delete или явного освобождения каких-нибудь ресурсов.

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

Partner

ЗачОт)))))))

 

SII

Паскаль (1970), Модула (1978) и Оберон (1986-89) разработаны Никлаусом Виртом.

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

 

SII

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

Код (Text):

1. var
2.   i : integer;
3. begin
4. ....
5.   for i := 1 to 10 do ....
6. ...
7. end

И С++:

Код (Text):

1. {
2. ...
3.   for (int i = 1 ; i <= 10 ; i++) ... //переменная i локальна для этого цикла, ее нельзя использовать по ошибке где-то еще и она не мозолит глаза читателю этого кода
4. ...
5. }

 

SII
насчет '=' и '==' - таки да, кривовато придумали, потому я юзаю '-'.
а ':=' и '=' - однозначно плохо, тк '=' встречается значительно реже ':=', в особенности в пасе. Ну и сама комбинация ':=' - неудобная. Можно было чтото без шифтов придумать.
Еще что мне не нравится в пасе - отсутствие препроцессора.

skomarov

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

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

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

Кста, а че это 'вы'?! А вы сами - не программист? Разберитесь как оптимизаторы работают, расковыряйте кодогенератор дельфей, напишите свой оптимайзер и влепите его в дельфу. Вот тогда вас и слушать начнут ибо будете вы уже 'гуру', если, конечно, говорить захотите.

 

_basmp_

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

 

SII

Есть он, масм. Если пишу я mov eax,ebx то он так и скомпилит.

 

skomarov

Если вы про лаконичность, то С официально появился и начал популяризоваться/рекламироваться практически одновременно с пасом, а В - предок С, отличавшийся в основном системой типов - еще раньше. Да и зарождалось оно на то время уже лет 20. Пас и С - не первые языки. Васик и то - старше.

 

Ты бы после тулзы от dermatolog`а глянул бы !

Пока раз 30 не ошибешься и не поотлаживаешь прогу, понимание этого мракобесия не приходит!

Aquila:

Ну на delphi пишут тоже не за "спасибо" и причем пишут довольно быстро !

вот я одного увидел и смысл в этом: "дельфи код не понятный генерит", а спрашивается нахера заказчику шарить какой там код? А нахера знать программеру какой нафиг код работает у заказчика через полгода? Лично мне пох!
Ктото говорит, файлы большими получаются. Но вот в среднем скажем, максимальная прога была у меня на 10 МБ,но я старался и очень, накидывал туда картинок, иконок и т.д. и т.п. Честно ? Да пофиг на эти занятые 9 МБ , у меня хард на 140 ГБ и на эти 9 МБ .... вобщем на эти 9 МБ даже порнуху не запишешь, не говоря о какой-либо серьезной проге, к примеру IDA Pro.

 

Clerk

Да ладно. Я на масм почти не писал... быстро бросил и перешёл на фасм. Отчасти как раз потому, что и масм своевольничает. Не помню, что мне тогда не понравилось... но как пример: таблица импорта "дополняется" "оптимизирующими" мостиками в виде заранее известного числа косвенных jmp'ов в конце кодовой секции. А вызовы импортируемых ф-ий выполняются прямыми call'ами на эти мостики.
SII K10

Ну вот это не аргументы. Как написать код, зависит от программиста. Синтаксис Вам предлагает возможности, а не использовать их - Ваше право. Кроме того нечитабельную прогу в паскалевском синтаксисе написать - раз плюнуть. If-then-else'ов и циклов в одну строку можно так понаписать, что легче будет скомпилить и читать в дизасме. Если программисту не дано писать читабельные проги, то это его проблема, а не проблема синтаксиса.

 

А причём тут пас? Это в делфи отсутствует препроцессор. Попробуй FreePascal.

То что не нашёл можно и самому написать (хотя и соглашусь что на C больше всего понаписано).


И в который раз убеждась, что многие считают делфи средой для формошлёпства (и в добавок ассоциируют это с паскалем).
Лично я выбрал паскаль по след. критерям (юзаю как Delphi, так и FPC):
1) строгость языка
2) читабельность исходников (почти постоянно портирую сорцы с Си на Пас; С-код мой мозг медленее разбирает =)
3) поддержка asm вставок (ну не могу я без них)

Не убогий, а строгий.

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

 

один уже понял ! Что не язык красит программиста, а программист язык! Именно ради этого и создал тему и изначально написал слова:

еще в первом посте!

 

scf

Озвученная Вами проблема действительно существует, но, ИМХО, Вы преувеличиваете её значение. Лично меня, наоборот, раздражает подобная "автоматизация" (кроме некоторых специфических случаев вроде обработки длинных строк). Например, если я пишу процедуру Init, у меня будет и процедура Done, и действия в них будут "симметричными"; в частности, если в Init создаётся экземпляр какого-то класса, то в Done он будет уничтожаться (если, конечно, логика программы не требует другого подхода). Хотите верьте, хотите -- нет, но проблем с утечками памяти у меня не возникало ни на Паскале, ни на асме -- вероятно, из-за подобной дисциплины проектирования программы. Кстати, try-finally использую крайне редко.

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

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

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

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

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

skomarov

Между прочим, я пишу как раз в основном на Дельфи, а на сях -- только под страхом смертной казни Ну а во-вторых, как Вы себе представляете "оптимизатор дельфийских экзешников"? Вы хоть отдаёте себе отчёт, в чём должна заключаться оптимизация и как она осуществляется?

scf

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

_basmp_

Насчёт первой части не понял, что же плохого в том, что = встречается реже, чем :=. Где Вы видели, чтоб все операции встречались одинаково часто? Тогда * и / стопудово хуже, чем + и -.

А насчёт удобства набора := -- это вообще никакого отношения к языку не имеет, по большому счёту. Лично я неудобств никаких не испытываю (в т.ч. из-за привычности, конечно). Зато никак не поставишь лишний =

Clerk

Вообще-то речь о ЯВУ шла, а не об ассемблерах.

 

EvilsInterrupt

А причём здесь какая-то тулза? Я говорил о компиляторе фирмы Борланд, и точка.

l_inc

Это как раз аргументы, а Ваш подход не очень-то аргументирован. Язык должен поощрять хороший стиль программирования. Конечно, написать жутко криво можно и на Паскале, но на нём это сделать куда сложнее. А на Си -- запросто, достаточно лишь пользоваться штатными возможностями языка. Другое дело, что лёгкость написания нечитабельного кода на Си лично для меня не является "фатальным" аргументом против этого языка: таким аргументом для меня является, как я уже выше где-то писал, отсутствие вменяемого контроля типов и лёгкость случайных ошибок в ==, && и т.п. операциях.

T800

Ну, вообще-то в Паскале препроцессора нет. Другое дело, что он и не нужен. Это ещё один из кошмаров Си, от которого, ИМХО, куда больше вреда, чем пользы. А какая возможность запутать программу

EvilsInterrupt

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

 

SII

Вобщето форум этот по ассемблеру.

 

SII

Долго думал, но так и не понял: программист по отношению к языку - это человек или одежда? ИМХО неудачное сравнение.

И да, и нет. Если у Вас есть возможность написать a = b = c+++b == a, то это возможность. Можете её и не использовать. Паскалевский синтаксис не просто "поощряет хороший стиль". Он его навязывает. А хороший он или нехороший - это уже относительно субьективно.

Что значит "вменяемый контроль"? Можно примеры сравнения сишного и паскалевского варианта? Очень давно на паскале не писал.

Ну здесь, пожалуй, могу согласиться.

 

Замена BEGIN, END, mayVar := mayVar * 5, mayVar := mayVar + 1
на сишные {,}, mayVar *= 5, ++mayVar имхо большой и удобный плюс - лучше тратить нажимы клавиш на написание логики кода и комментариев, чем лишних букв в тексте программы

не люблю когда компилятор генерит что-то типа

Код (Text):

1. push MB_OK
2. call SkipText_1
3.   db 'Title',0
4. SkipText_1:
5. call SkipText_2
6.   db 'Hello Word',0
7. SkipText_2:
8. push 0
9. call MessageBoxA

и т.п. пакости и не позволяет переучить его независимо от квалификации программирующего.

 

SII

А при том что подавляющее большинство программистов работает хоть и в свое удовольствие, но за деньги! Как правило у них возникает задача защит их творений! Вот тут-то код который скомпилил к примеру MS Visual Stuido 2005 TS программист как правило пропускает через какой либо пакер! А после пакера код, о чистоте которого так тут беспокоятся становится ни чем не лучше кода, который получился в результате Delphi компиллера !
Ну сомневаюсь, что вы написавший действительно нужную прогу, которая позволяет решать множество задач и с хорошим интерфейсом и довольно эффективно работающая в плане выполнения процессором и мало занимает памяти. Сомневаюсь что вы по собственной инициативе в голом виде поставите е пользователю, понадеявшись на то что он действительно по оканчании триал-срока заплатит честно вам ваше честно заработанные деньги!

Это к тому что не стоит уж так сильно радеть за чистоту генерации кода! Ведь в конечном итоге мы очень редко заглядываем на уровень асма при написании на ЯВУ ! А после написания программы, мы не оставляем ее в открытом и нативном виде!