лыко в строкубуду педантом, но разве longjmp в C не делает этого?
Хм. longjmp возвращает управление в указанную точку, а не передает . Пара setjmp/longjmp в чем-то аналогична бейсиковским gosub/return, но при этом longjmp играет роль именно return-а. И при этом отсутствует возможность вызвать подпрограмму (завершающуюся этим return-ом) с произвольного места, как оно возможно в случае gosub.

Пожалуй, рискну утверждать, что бейсиковский код вида


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

Если искать среди бейсиковских конструкций аналог longjmp, то это RESUME, хотя сходство все равно очень дальнее.

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

c127Формат часто бывает очень удобен. Правда его легко сэмулировать. А чем он еще перегружен?

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


и


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

Другие неудачи - вычисляемый GOTO и арифметический IF как довольно неуклюжие замены case/switch. COMMON области как неуклюжие замены глобальных переменных (я бы сказал даже, не столько глобальных переменных, сколько конструкции record/struct. Структуру нетрудно передать параметром подпрограммы, в отличие от пятидесяти ее полей поодиночке - поэтому ее и передавали через common область). Напрасное, с моей точки зрения, выделение трех (если не изменяет память) принципиально разных типов подпрограмм. Назначаемый GOTO - специфическая конструкция, мягко говоря не для "языка для непрограммистов". Замечательный оператор IMPLICIT :) Наверное, если откопаю книгу, еще что-нибудь вспомню.

eНу да. Переведите один в один
subroutine f(n)
real y(n)
return
end[/quote]
Признаться, не понимаю этого фрагмента. Судя по Вашим словам, этот массив должен каким-то образом вернуться из подпрограммы, но каким - видимо, я либо тупой, либо слишком хорошо забыл Fortran.

Впрочем, согласитесь, "создание массива размерности N" переводится на Си совершенно элементарно. Здесь оказывается очень удобной особенность "массивы есть указатели" - что в случае


что в случае


работа с массивом a идет абсолютно одинаково. Собственно, если бы я писал конвертор, я бы, наверное, просто всегда пользовался вторым вариантом.

Совершенно верно, а больше и не нужно. Сила фортрана в том, что он имеет достаточно необходимых средств и не имеет много лишних.
Я не считаю, что отсутствие развитых циклов, например - лишнее. Арифметический цикл - хорошо, но стандартнейшая задача "арифметический цикл с условием досрочного выхода" - решается в PL/I, решается в паскале/си, но не в фортране. Вернее, если не ошибаюсь, в фортране она решается на уровне IF..GOTO - можно, в принципе но не лучший вариант.

Если говорить о вычислениях - давайте вспомним о такой стандартнейшем математическом приеме, как вычисление с переменным шагом (не помню, как это называется "по научному", но абсолютно стандартная вещь для задач типа "интегрирование с заданной точностью"). В Си это - тот же цикл for. В Паскале это - например, цикл while. В Фортране это - IF/GOTO.

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


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

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

Все равно всеми возможностями цикла for никто не пользуется.
"Отучаемся говорить за всех" (c)

Знаете, пока я не поработал с исключениями, вполне нормально делал аналогичные механизмы имеющимися средствами. Пока я не поработал с LISPом - не ощущал отсутствия некоторых его конструкций в других языках. Пока не ушел с Си на "не Си" - считал операцию ? удобной, но не более того. И так далее. К хорошему привыкаешь, и учишься его хорошо использовать.

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

Как модно нынче говорить, there is no silver bullet.

Формальные параметры ОЧЕНЬ ХОРОШИЙ АРГУМЕНТ. ИМХО. Ваш аргумент с циклами по сравнению с ним совсем не в тему. Опять же ИМХО.
Конечно, можно сойтись на имхах. Я бы сказал так: цикл - более "коренная", необходимая структура языка, нежели подпрограмма, следовательно и сходства-различия в них более важны с точки зрения похожести. Ну а фантазировать "какими были бы подпрограммы в первых бейсиках, если они там были..." Но не было. По сути, от них отказались так же, как и от некоторых других фортрановских конструкций.

softwarer
Учитывая, что в первых бейсиках по сути не было подпрограмм, в них действительно трудно найти формальные параметры :)


Подпрограммы были, можно было написать что-то вроде

200 ....
300 return

go sub 200
....
go sub 200

То что между 200 и 300 и есть полноценная подпрограмма, которая вернется в точку вызова.
Полноценная подпрограмма? Думаю, мы не сойдемся в определениях. Близкий аналог этой конструкции я использовал в bat-файлах (помните такой язык для DOS?) примерно так:


Бейсиковские GOSUB/RETURN - это именно что аналог setjmp/longjmp в Си или назначаемого GOTO в Фортране, но подпрограммами это - только называется.

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

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

Я бы сказал, параметры есть естественный атрибут подпрограмм; невозможно понять смысл подпрограмм, не поняв смысла их параметров. Проведение именно здесь какой-то границы между "гуру" и "домохозяйками" - имхо, совершенно произвольный жест. Хотя все - понятие относительное. Мой научный руководитель говорил, что не понимает указателей, что не мешало мне научиться у него некоторым интересным способам программистского мышления.

Поэтому я считаю что аргумент с формальными параметрами очень удачен.
С какой точки зрения? Как различие между языками - безусловно, важное различие. Но это ровно никак не относится к обоснованию или опровержению моего утверждения (о том, что бейсик разрабатывался как идеологический наследник фортрана).

Позволю себе использовать Ваш аргумент: если из Фортрана "для простоты" убрали циклы, кроме тривиального, то в Бейсике развили эту идею и "для простоты" убрали "параметры подпрограмм" (с Вашей точки зрения) или "подпрограммы" (с моей).

Подчеркну на всякий случай: это не есть утверждение, которое я считаю верным. Это опровержение Вашей схемы рассуждения методом "от противного".

c127 softwarer
[quot c127]Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная.
Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было.

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

Ну а то, с какой осторожностью надо использовать common области, полагаю, не мне Вам рассказывать.

c127При чем тут шире-не шире, я такого не говорил. Я не думаю что бейсик какой-то особый наследник фортрана.
Хм. Я думаю, что Бейсик - наследник Фортрана. Чингиз, а следом и Вы, решили поспорить с этим, выдвигая основным аргументом отсутствие одной из конструкций, существующих в Фортране - то есть то, что Бейсик не реализует одной из важных особенностей "предка".

Поэтому я и сказал, что наследник вовсе не обязан быть "шире" предка; тезис "уже - значит, не наследник" не представляется мне бесспорно верным.

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

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

Кроме того такого изобилия языков как сейчас не было и по-видимому создатель бейсика знал о фортране и ничего другого не мог себе представить.
Не соглашусь. К тому моменту существовало порядка десятка "основных" языков, тех, названия которых сейчас можно вспомнить не напрягаясь: FORTRAN, ALGOL, APL, SIMULA, PL/I, COBOL, LISP. И на самом деле тогда был некий взрыв языкотворчества; раскрывалась новая область, из которой до нас дошли наиболее удачные либо наиболее удачливые представители.

Изменил как мог. Хотя цели и предполагаемые пользователи этих языков совершенно разные.
Цель - учить тех, кто потом будет программировать на Фортране. "И программировать для тех, кому Фортран сложен" - это уже мое дополнение; это не было изначальной целью, но именно для этого Бейсик как Вы выразились, "реанимировали".

WHILE не сильно нужен, а компилятор упрощается. Экономили, в этом причина.
WHILE сильно нужен, по крайней мере с точки зрения человека, у которого была возможность выбора. Что касается экономии - я приму этот аргумент для Fortran I-II, но не очень поверю в него для Fortran IV. Если помните, к тому моменту IBM разработала совершенно монструозный по отзывам современников, четырехпроходный, кажется, компилятор, выполнявшийся отдельными стадиями - говоря современным языком, для полной компиляции требовалось запустить несколько exe-шников по очереди. Так что в аргумент "экономили" верится, признаться, с трудом.


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

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


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

Говорят в С это тоже как-то возможно, но как не знаю, а думать лень.
Полагаю, если говорить о нормальных конструкциях языка, о подразумеваемом их использовании, говорят ошибочно. Разумеется, это можно сделать с помощью адресной арифметики - сотворить указатель на (&func() + 0x20), например, и перейти по нему.

"вынуждало" это сильно сказано, можно обойтись без него.
Технически - можно. Например, оформлять на месте операторного блока вызов подпрограммы. Но в данном случае "все и всегда" делали именно GOTO - собственно, во многих версиях Бейсика даже не было возможности написать в IF что-то отличное от GOTO.

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

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

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

softwarer
- Cхема работы бейсика с файлами была почти стопроцентно слизана с фортрановской.
Этого я не понимаю. Схемы работы с файлами по-моему вообще у всех одинаковые.
Да не сказал бы. Признаться, не помню как в ALGOL и PL/I - может, это было обычно в те времена - но по сравнению с более поздними временами эта схема раритетна. В классическом паскале она достаточно похожа, но все-таки введено важное понятие "файловой переменной"; в результате, например, файл можно передать параметром в подпрограмму. В Си и в более поздних версиях Паскаля сделано правильнее: работа с файлами убрана на уровень библиотек, функций/классов с уровня операторов языка.


STOP

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

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

действительно метка. В фортране метки в разных подпрограммах могли дублироваться, а в бейсике номера строк - нет.
Дык в бейсике и не было "разных подпрограмм" в фортрановском смысле - там был единый контекст выполнения, общие переменные, ну и общая область видимости меток.

Если делать конвертор бейсика в фортран - надо будет делать всю бейсик-программу единственной SUBROUTINE, а GOSUB/RETURN реализовывать как раз тем путем, который я описал выше, в примере бат-файлов - через назначаемый GOTO. Полагаю, Вы согласитесь с тем, что любая другая реализация конвертора окажется много сложнее, а результат ее работы - дальше от исходного варианта.

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

c127Если Вы посмотрите на языки действительно той поры (60-е годы), то наверняка увидите что они очень похожи.
Я назвал те отличия, которые выделяют из. Тот же Алгол - наличие операторных блоков, предобъявление переменных, сильная типизация, вообще явный предок Паскаля. PL/I - своеобразный язык, но тоже скорее алгольного типа; в нем, кстати, присутствовала конструкция "арифметического цикла с условием" - не помню как записывалась, но по смыслу именно что


someCondition, естественно, задавался программистом. APL - особая вещь, пожалуй что равно далекая от всего перечисленного. Вот пример текста на нем (обратите внимание на операторы get и set):


SIMULA - никогда не видел, не знаю, на что она похожа. LISP, опять-таки - совершенно особая вещь. Функциональность тут особо не при чем; R-LISP - вполне себе алгоритмический-процедурный, но его все равно ни с чем не спутаешь :)

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

tchingiz
в любом интерпретаторе не надо обьявлять переменные.
Глупость. Наиболее популярный нынче пример обратного - Java.

tchingizкстати, perl удовлетворяет Вашей просьбе назвать язык, где бы
имя переменной задавало тип.
То есть собственного примера Вы привести не можете, берете из обсуждения.

Кстати, напомню что в Перле вообще весьма специфичное понимание переменных; так, $a в нем с равной вероятностью может оказаться строкой, числом или объектом, а $a и @a, хоть и вроде разные вещи - но внутри оказываются двумя ипостасями одной переменной.

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

Думаю, что бейсик был позже фортрана,
Это так.

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

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

В качестве сходного примера - Паскаль, как известно, строился на основе Алгола. Однако, отказался от алгольной возможности объявления переменных во вложенных операторных блоках; в Паскале локальные переменные можно объявлять только в заголовке подпрограммы. Если брать примеры посвежее - C++ отказался от элегантности и простоты C в пользу мощи; отказался от слабой типизации в пользу типизации сильной. java и C# дружно потеряли основное хорошее качество своего явного предшественника - множественное наследование, а заодно и от макросов.


сомнительно Ваше утверждение
softwarer>Фортран - предок бейсика
Да, в общем, сомневайтесь если хотите. Правда, в первой же процитированной фразе Вы уверенно изрекли.. куда более сомнительное утверждение.


вот язык ratfor (rational fortran)
разработанный как препроцессор для фортрана под никсами уже обладал
всеми атрибутами структурного программирования (циклы while, until,
отсутствие меток и операторные скобки),
Причем Фортран сам по себе также обладает всеми необходимыми для структурного программирования конструкциями, а названное скорее провоцирует заподозрить Вас в приверженности популярной благоглупости "структурное программирование - это отказ от GOTO".

и все равно мог бы считаться
наследником фортрана.
Формальная грамматика ратфора представляла из себя 10-12 строчек.
Это, простите, ересь. "Препроцессор" не может считаться наследником компилятора - в противном случае утилиту grep можно обозвать наследником "Войны и мира", по которой она делает поиск.

Если же говорить о языке вида "препроцессор плюс собственно фортран", то я не вижу ничего, что помешает ему быть "наследником фортрана", но было бы интересно посмотреть на его грамматику из 10-12 правил.

tchingizДля своей версии ратфора, я еще добавил операции ++, --, +=, -= и тд.
И думаю это не изменило свойства фортрана быть предком ратфора от меня.
))))))))
Осталось понять, к чему Вы это рассказали. Боюсь, единственная связь, которую я могу придумать - Вы пытаетесь опровергнуть мое утверждение методом "раз вот это - наследник, то не похожее на это - не наследник".

c127 softwarerВозможно, тут вопрос подхода. С моей точки зрения то, что может быть вынесено из языка, должно быть вынесено из языка - это собственно и есть "разгрузка".

Тогда давайте уберем из С цикл while, сишного for достаточно. Кстати я бы так и поступил на месте авторов С.
Не понял логики. "Разгрузкой" было бы "давайте уберем из C цикл вообще".

Насчет "Вы бы так и поступили" - вполне возможно, именно поэтому Вы и ратуете за фортран :)

Постараюсь донести свою мысль максимально аккуратно. Итак, если у нас есть
эквивалентные оператор WRITEFILE и функция WriteFile, второе представляется мне более удачным решением, поскольку это "отъемлимая", если можно так выразиться, часть языка, часть, объективно склонная к изменениям; стандартизируя ее в языке, мы тем самым душим ее развитие. Это хорошо видно на примере паскалевских файлов - сегодня работать с ними неудобно, незачем и я бы сказал, глупо; виртовские методы поддерживаются только для совместимости. В то же время я приветствую уместное разнообразие правильных способов выражения мысли; скажем, несколько версий функции WriteFile. Цикла for действительно было бы достаточно, но - ключевым достоинством Си является "четкость и лаконичность выражения мысли", чему наличие while весьма способствует. Собственно, если бы его не было - все подряд делали бы макрос while, делающий то же самое, что вряд ли было бы хорошо.

c127Объяснял уже, в тех задачах case/switch не используется почти никогда. Когда создавали фортран о нем никто не подозревал. Потом его ввели в язык.
Хм. Я кажется уже объяснял, что я нисколько не нападаю на язык, в том плане что абсолютно не стремлюсь доказать "он плохой". Я отвечаю на Ваш же вопрос.

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

c127 softwarer
COMMON области как неуклюжие замены глобальных переменных (я бы сказал даже, не столько глобальных переменных, сколько конструкции record/struct. Структуру нетрудно передать параметром подпрограммы, в отличие от пятидесяти ее полей поодиночке - поэтому ее и передавали через common область).

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

c127 softwarer
Напрасное, с моей точки зрения, выделение трех (если не изменяет память) принципиально разных типов подпрограмм.

В паскале тоже три: program, процедура и функция.
Program тут не при чем. А разницу между процедурой и функцией весьма стремительно сгладили, что пожалуй является лучшим аргументом в пользу того, что изначальное решение сделать ее было неудачным.

c127 softwarer
Назначаемый GOTO - специфическая конструкция, мягко говоря не для "языка для непрограммистов".

Назначаемых это вычисляемый?
Нет, назначаемый это назначаемый


c127Неудобно, но почти никогда не используется, нетипичен для тех задач. Уже обсуждался.
Я бы не сказал, что он не использовался. Использовался, и активно. Но пал первой жертвой структурного программирования.

c127Это тоже уже обсуждалось, экономит объявления переменных.
Хм. Никто не говорит, что "абсолютно бесполезен". Я, если помните, отвечаю на вопрос о перегруженности. И с моей точки зрения, "перегрузить программу объявлениями переменных" - куда более полезных вид этого занятия.

c127Нет, это пример того, что ошибку с освобождением памяти сделать труднее.
А, вот Вы о чем :)

Это актуально если сравнивать ручное программирование. Но именно эта фраза возникла в контексте конвертора Фортран -> Си - а в нем "ошибку с освобождением памяти" сделать столь же трудно.

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

c127Еще раз: развитый цикл запутывает опртимизатор.
Еще раз: не запутывает. А вот "имитация развитого цикла подручными средствами" - та да, чтобы ее распутать, нужно потрудиться.

c127К тому же ими почти никто не пользуется.
Хм.

c127GOTO неудобно, согласен, для выхода из цикла в поздних версиях фортрана был введен оператор типа break.
Это утверждение выглядит странно, если сопоставить его с более ранним "я бы оставил в Си только FOR, убрав WHILE".

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

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

c127 softwarer
Если говорить о вычислениях - давайте вспомним о такой стандартнейшем математическом приеме, как вычисление с переменным шагом (не помню, как это называется "по научному", но абсолютно стандартная вещь для задач типа "интегрирование с заданной точностью"). В Си это - тот же цикл for. В Паскале это - например, цикл while. В Фортране это - IF/GOTO.
Или тот же do c выходом по условию.
С каким выходом и по какому условию?

Еще раз: цикл с переменным шагом . Примерно так:


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

softwarer
К чему я это - к тому, что у Фортрана как языка нет никаких особых преимуществ по оптимизации.

Программы флоат вычислений, написанные на NDP фортране работал в 2 раза быстрее чем такие же на NDP С
Как факт - верю. Но сомневаюсь, что Вы покажете мне неустранимую причину этого. Скорее всего, в оптимизаторе C ставили другие задачи.

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

Неужели вы используете ВСЕ возможности оператора for? Как часто?
Что именно Вы называете "все возможности"?

Как простой эксперимент - я перебрал циклы for в нескольких модулях, прямо сейчас открытых у меня в IDE. Где-то четвертая или пятая часть из них содержит "навороты".

с127 softwarer
Хм. Так если помните, эта часть беседы началась с фразы одного из присутствующих о полной прикладной победе Си. Я ответил на это, что лет двадцать назад это же могли бы сказать о Фортране - и были бы столь же корректны.
Некорректное сравнение. Фортран никогда не продвигался как универсальный язык.
Да и Си тоже - до тех пор, пока не пошел маркетинг. А под маркетинг могло попасть что угодно.

Такое впечатление, что Вы принципиально не осознаете логику доказательства "от противного". Я показываю "явно сомнительный пример, похожий на названный" - а Вы тут же начинаете оспаривать именно мой пример.

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

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

ЯзыкАриф. цикл.Расш. ариф. циклЦикл с предусловиемЦикл с постусловиемBASICFOR---FORTRANDO---PASCALFOR-WHILEREPEATCFORFORWHILEDOPL/I++??

Итак, глядя на эту таблицу, мы видим, что Бейсик больше всего похож на Паскаль, поскольку циклы называются одинаково :)

И кстати - почему именно на Паскаль? В Си цикл тоже называется FOR. При этом Фортрановский и Бейсиковский цикл умеют одинаково (что в Вашей логике не аргумент), а вот сравнение Паскалевского с Бейсиковским интересно: каждый из них умеет то, чего не умеет другой.

softwarer
Я бы сказал, параметры есть естественный атрибут подпрограмм; невозможно понять смысл подпрограмм, не поняв смысла их параметров.

Именно об этом и речь, бейсиковцы их и не понимали. Подпрограммы (ИМХО) были, а параметров - не было. Программисты не привыкали к правильно думать.
Чем же это подпрограммы? Если говорить в терминах Си, это пара setjmp/goto (аналог GOSUB) и longjmp (аналог RETURN). Это даже слабее, чем ассемблерные подпрограммы.

Цикл есть цикл, даже если он записывается как goto, от этого ничего не меняется. А если нет формальных параметров это все, их ничто не заменяет.
Да бросьте. Точно так же заменяется.


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

softwarer
c127Еще в фортране были блоки common и equivalence аналогов которым в бейсике вообще не было, а штука удобная.
Насчет "удобства" - скажем так..... Это не то что было удобно, просто альтернативы вообще не было.

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

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

Ключевое слово - важной. Опять вопрос классификации.
Отнюдь, не ключевое. Для примера - покажите ложное из следующих трех утверждений:

1. С# есть наследник C++
2. Важной особенностью C++ является множественное наследование
3. C# не допускает множественного наследования.

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

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

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

softwarer
Да не сказал бы. Признаться, не помню как в ALGOL и PL/I - может, это было обычно в те времена - но по сравнению с более поздними временами эта схема раритетна. В классическом паскале она достаточно похожа, но все-таки введено важное понятие "файловой переменной"; в результате, например, файл можно передать параметром в подпрограмму. В Си и в более поздних версиях Паскаля сделано правильнее: работа с файлами убрана на уровень библиотек, функций/классов с уровня операторов языка.

Номер файла тоже можно передавать в подпрограмму.
И так было изначально? Хм, возможно здесь меня подводит память.

С непроцедурными языками сравнивать не нужно. Во-первых это и тогда и сейчас очень большая экзотика, а во-вторых ....
Хм. Возможно, я неправильно понимаю смысл "процедурного" языка. В том, на что Вы отвечаете, названы ALGOL, PL/I, Pascal, С. Кто из них менее процедурен, чем бейсик, и почему?

maytonМне кажется что для C++ циклы for и while - идентичны.
Теоретически - да. Но их идентичность не особо жизненная; скажем, чтобы справится со следующим упрощенным примером:


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

tchingizнаверно, не забуду никогда мудрую строчку из руководства по бейсику, написанного в 88 году (уже при живом паскале и си) :
"когда нумеруете строчки программы, делайте это с шагом 10,
чтобы была возможность вставлять новые строчки при изменении программы.
Чем же она мудрая? Учитывая, что существовал замечательный оператор RENUMBER. А глупостей можно откуда угодно и сколько угодно нацитировать, дефицита не предвидится.

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

tchingizЯва - сомнительный контрпример. Она далеко не интрепретатор.
Видимо, она неизвестный науке зверь. Да, правы были классики: "если факты противоречат теории - тем хуже для фактов".

tchingizИнтерпретатор (как бейсик ) можно было использовать для вычисления каждой отдельной строчки.
Как минимум, очень неудачная формулировка. Честно говоря, хочется назвать ее бредовой. Интересно было бы посмотреть, как интерпретатор бейсика вычислит вполне себе синтаксически верную строчку


или хотя бы столь же синтаксически верную


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

tchingizне поленился почитать в справочнике Болски язык программирования си.
Оказалось определения глобальных переменных в си противоречит Вашему мнению. к глобальным переменным в си, тоже доступ был не отовсюду.
Будем считать, что Вам виднее.
Насколько я помню, в старых бейсиках определение глобальных переменых
совпадало с Вашим и было отлично от фортрановского.
Не совсем так. В Си введена новая по сравнению с Фортраном и Бейсиком логическая единица кода - файл. Введена именно в язык, следствием чего явилось ограничение области видимости и директива extern. В Фортране, если мне не изменяет память, многофайловость поддерживалась компилятором (посредством библиотек), но логически программа являлась одним файлом.

Соответственно, если взять Си-программу, состоящую из одного логического файла (который может включать другие по #include), то в ней глобальные переменные ведут себя именно таким вот, "бейсиковским" образом. Здесь также важно помнить об отличии глобальной переменной и локальной статической.