softwarer
Постараюсь донести свою мысль максимально аккуратно. Итак, если у нас есть
эквивалентные оператор WRITEFILE и функция WriteFile, второе представляется мне более удачным решением, поскольку это "отъемлимая", если можно так выразиться, часть языка, часть, объективно склонная к изменениям;
У паскаля та же проблема что и у фортрана. Тут С со своими библиотеками скорее исключение, а не правило.
У оригинального - безусловно. И от этого быстро стали уходить. Подход Си на тот период, безусловно, был на голову впереди прочих.
Цикл while(предикат){...} полностью эквивалентен цииклу for(;предикат;){...}. Даже символов получается одинаковое количество. Поэтому я не понимаю что в данном случае дает введение дополнительного оператора в язык, никакого выигрыша в смысле лаконичности не получается.
OK. Давайте считать, что я вижу.
Да, но эти кирпичики жрут основное время счета. Их удобно писать на фортране. Операторы switch это в большинстве логика работы программы (это нестрого), но в рассчетах они встречаются редко. Логику нужно писать, например, на С. Когда связка фортрана с С была проблемой, все писалось на одном языке, по-видимому поэтому в Вашем примере в фортране встречалось много конструкций эквивалентных switch.
Признаться, не вижу смысла по столь мелкому поводу разводить зоопарк языков.
Сгладили только в С и всем что от него пошло, типа джавы, пошарпаного С, С++ и пр.
Отнюдь. Вы снова выдвигаете аргумент в стиле "потому что называется одинаково". Я все же предлагаю смотреть глубже; иначе придется, например, считать, что Рапира не имеет ничего общего с Фокалом (или из чего там ее сотворили), а Фотон - с Multi Edit-ом.
Я говорил о ручном программировании, ясно что правильный конвертор все проконвертит правильно, но я думаю о себе. Ошибка основная, если ее убрать то С станет вполне даже приличным языком.
По большому счету она уже давно убрана :)
softwarer
В ручном кодировании, безусловно, об этом нужно помнить, но здесь у каждого языка свои фокусы - вспомним, например, классический фортрановский прикол с изменением значения константы.
Освобождение памяти более серьезная ошибка и более часто встречающаяся. А что там с изменение констаны, это оператор DATA?
Замечательная логика - "не понял, о чем идет речь, но сишная все равно чаще".
Нет, это не оператор DATA - тот работает вполне предсказуемо. Это следующий прикол:
1.
2.
3.
4.
5.
6.
7.
8.
9.
subroutine X
call Y ( 3 . 14 )
call Z ( 3 . 14 )
return
end
subroutine Y (P)
P = 2 . 78
return
end
Я константы всегда объявлял константы как parameter, вроде поменять нельзя, но возможно ошибаюсь. Но это поздние версии фортрана.
softwarer
c127GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break.
Это утверждение выглядит странно, если сопоставить его с более ранним "я бы оставил в Си только FOR, убрав WHILE".
Речь шла только о сишном for, он эквивалентен while, в фортране, паскале while нужен, там цикл его не заменяет.
И что? BREAK эквивалентен GOTO; по той же самой логике он в фортране не нужен. Да и в остальных языках тоже.
softwarer
BREAK - это одна из форм оператора GOTO. Всей разницы - экономия нескольких символов на метке. Это ровно такая же приятная мелочь, синтаксическое удобство, как и сишный цикл while.
GOTO запутывает оптимизатор, оптимизатор не знает куда будет переход. BREAK учесть легче, это частный случай GOTO.
Насколько я готов утверждать без доставания книги по оптимизации - никакой разницы. В любом случае анализируется граф переходов.
Та же история что и с циклами, чем более общий случай тем труднее его оптимизировать.
Отнюдь не та же. У упомянутых циклов - разные возможности. break и goto - близнецы-братья.
Если не ошибаюсь на момент создания фортрана структурного программирования не было и близко.
Хм. Знаете, я пожалуй завершу этим письмом наше обсуждение. Вы зачем-то ведете в сторону "я защищаю язык, на который софтварер нападает".
Когда концепция появилась фортран подрехтовали, теперь на нем легко можно программировать структурно без GOTO. Для этого потребовалось 3 оператора: switch, while, break. Не так много.
Во-первых, прошу таки помнить, что "структурно" и "без GOTO" - абсолютно разные вещи. Не составляет ни малейшей проблемы написать классический спагетти-код без единого GOTO.
Во-вторых, я так понимаю, что в каких-то из новых версий недостаточность управляющих конструкций таки исправили. Это, безусловно, хорошо, и это же доказывает, что она была.
softwarer
Еще раз: цикл
с переменным шагом . Примерно так:
for (float x = x0; x <= x1; x += someVariableExpression())
Вот и попробуйте соптимизировать такой цикл. Компилятор вообще не знает что там происходит. По этой причине вообще циклы не оптимизирует на всякий случай. Шучу конечно, но доля правды есть.
Не уходите в сторону. "Доля правды" есть в том, что цикла DO не хватит для реализации такого цикла, соответственно его возможностей недостаточно для типичной, подчеркиваю, задачи численных вычислений.
Другая доля правды - такой цикл тем не менее можно оптимизить, а вот его же реализацию через IF/GOTO - можно, наверное, но сомневаюсь, что писали столь развитую логику.
А в фортране цикл определяется таким образом, что на момент входа в цикл программа знает сколько раз он будет выполняться. Единственный способ прервать - опрератор break, который в языке появился. А goto компилятор запутывает, его использовать в этой ситуации не рекомендуется. И для которого из циклов легче написать оптимизатор по-Вашему?
На самом деле одинаково. Оптимизация цикла, если грубо, распадается на две группы: во-первых, преобразования, связанные со структурой цикла (например, вынесение константных операций), во-вторых, преобразования, связанные с вариантом цикла (раскрытие цикла, индуктивные переходы, изменение порядка обхода на нисходящий итп). Итого, разница только в выделении вариан(ов) цикла.
Неустранимой причины конечно же нет, все работаем на одной и той же машине Поста, но вот технические есть. Как результат в книгах по фортрану (например в книге "Оптимизация в фортране", автора не помню, книги нет под рукой) советовалось не выносить повторяющиеся вычисления из цикла с целью оптимизации, поскольку компилятор их найдет и вынесет сам и сделает это лучше, а вот компиляторы по С вроде очень часто не выносят и вычисляют каждый раз.
Хм. "Очень часто" зарождает подозрение, что идет сравнение с "обычным стиральным порошком", а хороший таки будет не хуже.
Трудно говорить о книге, которую в глаза не видел, но абстрактно можно отметить следующий факт: вынесение повторяющихся вычислений - преобразование, которое абсолютно не зависит от структуры цикла. От структуры цикла зависят индуктивные преобразования, но как раз в этом месте для C очень старались сделать эффективную оптимизацию.
softwarerНе очень вижу, за счет чего встроенный тип комплексных чисел будет оптимизиться сильно лучше, чем пользовательский, но и не решусь возражать.
А что тут смотреть, в С типа complex нет.
А в математических библиотеках для него - 100% есть. Точно так же, как и с файлами.
А лучше за счет того что: 1) программа где complex нужен получается компактнее,
C какой стати? Это еще можно было бы сказать об оригинальном, "системном" Си, но не о языке "прикладного периода".
2) библиотеки оптимизирует производитель компилятора а не я,
Лучше, если оптимизирует производитель библиотеки. А производитель компилятора сосредотачивается на оптимизации компилятора :)
с127Согласен, маркетинг штука страшная. Но во времена господства фортрана такой маркетинге никому не мог и присниться.
Я бы сказал, это чистой воды везение :)
К тому же так оказалось что С гораздо ближе к универсальному языку чем фортран, хоть и создавался совсем с другими целями. Мне он очень нравится. Если еще утечку памяти побороть, то вообще бы все было хорошо. Но как всякое универсальное средство С проигрывает специальным в их узких областях.
с127 softwarerВашу мысль стоит представить в табличном виде. Есть
Это была шутка, типа Ваша логика, доведенная до абсурда.
А с какого бока это была "моя" логика?
Мой оппонент пошел сравнивать по дико формальным признаком. Если не ошибаюсь, где-то у меня мелькнула фраза: "Вы еще скажите, что называются одинаково". И вдруг выясняется, что это моя логика..
softwarer
И кстати - почему именно на Паскаль? В Си цикл тоже называется FOR.
Потому что в С цикл for это нечто сложное, а у всех остальных - простое.[/quot]
Цикл FOR в бейсике много сложнее, чем в Паскале - он позволяет произвольный шаг, позволяет работать с вещественными переменными......
И что же это в цикле у паскаля такое, что не умеет фортрановский цикл?
for b := false to true do ...
Опять речь о терминологии. Ладно, пусть нет подпрограмм, тогда это делает бейсик еще менее похожим на фортран.
В этом случае "нет подпрограмм" - уникальная особенность "того" бейсика. Как, впрочем, и "нет формальных параметров" :)
Да, это различие. У любого языка есть различия с любым другим, даже если они очень похожи.
softwarer
Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет.
Да бросьте. Точно так же заменяется.
Это технически, а с точки зрения логики и понимания это существенная разница. Параметры это следующий после подпрограмм
типа GOSUB шаг в абстрактном мышлении.
Абсолютно те же слова можно сказать и про цикл. Но отмечу, что параметры - это не "следующий", а "тот же" шаг в мышлении. Альтернатива - сказать, что половину расстояния между концепциями "отрезка" и "треугольника" можно пройти, поставив на отрезок точку и назвав получившееся вырожденным треугольником.
Не знаю как оно было изначально, но в фортране 77 уже можно было по-моему.
По моим воспоминаниям, в Fortran IV номера файлов были "магическими числами". То есть в операторе ввода-вывода просто писалась константа и ничего другого сделать было нельзя. Почему я и выделил этот момент в сравнении с бейсиком, где по крайней мере в середине восьмидесятых еще было так же (сейчас, наверное, все же сделали нормально - не знаю).
softwarer
Хм. Возможно, я неправильно понимаю смысл "процедурного" языка. В том, на что Вы отвечаете, названы ALGOL, PL/I, Pascal, С. Кто из них менее процедурен, чем бейсик, и почему?
Все одинаково процедурны. А вот ЛИСП и АПЛ (по-моему), которые Вы вспоминали, не процедурные.
Я их вспоминал в другом контексте и по другому поводу.
Но на момент придумывания бейсика (середина 60-х) 1) паскаля не было,
Не было.
2) у алгола были проблемы с комрилятором, либо же компилятора не было вообще, точно не помню,
Хм. Не очень понимаю, о каких проблемах идет речь. В силу некоторых особенностей языка компиляторы Алгола были очень сложны в сравнении с современниками - насколько я помню, среди прочего Дейкстра доказал, что для ALGOL-64 теоретически невозможно сделать менее чем четырехпроходный компилятор. Но тем не менее по практическому использованию, они с Фортраном - ровестники.
3) ПЛ/1 не знаю был ли, может тоже не было.
Был. Появился несколько раньше бейсика.
Чтоб не ходить по кругу в вопросе о бейсике как наследнике фортрана предлагаю определиться. Я считаю что чтобы язык программирования D назвать наследником языка F необходимо выполнение двух условий:
1) авторы языка должны в явном виде заявить что D создавался на основе F
2) в момент создания D должен быть нацелен на решение тех же задач что и F
Хм. А Вы сможете назвать хотя бы одну пару из основных языков (не диалектов), для которых выполнятся оба этих условия?
Соглашусь, в такой постановке вопроса говорить о наследовании практически бессмысленно. Вывести Perl из какого-нибудь другого шелловского языка наверное еще получится, но не более того. Собственно, в такой постановке вопроса окажется непросто даже вывести Delphi как наследник Turbo Pascal-я :)
Поэтому бейсик НАСЛЕДНИКОМ фортрана назвать нельзя. Его можно назвать потомком, ответвлением, но не наследником.
Браво! Замечательно. Теперь позволю себе процитировать то утверждение четырехстраничной давности, с которого все началось, на которое и пошли ваши возражения:
softwarerФортран - предок бейсика, первый из проектов ряда "давайте программировать без программистов"
И вдруг, после стольких сломанных копий, оказывается, что с этим Вы и не спорите - Фортран предок, бейсик - потомок. Не нравится же Вам слово "наследник", вылезшее уже в середине обсуждения (на четвертой странице).
Если говорить о лишних и неудачных конструкциях в фортране, то они наверняка есть. Но все познается в сравнении, если посмотреть на другие языки, то там их как правило несравнимо больше, если фортран тут как-то выделяется, то только в лучшую сторону по-моему.
И снова начинается флейм на тему "лучше-хуже".
Нет, я таки завершаю эту беседу, тем более что как вдруг оказалось, Вы соглашаетесь с тем, о чем мы вроде бы начали спорить.
