Здравствуйте, Privalov, Вы писали:
P>Можно подумать, тот же C++ с ключевыми словами такого не позволяет.
Тогда в чем разница между зарезервированными и незарезервированными?
P>Когда служебные слова языка можно использовать в качестве идентификаторов, некоторые обязательно этим воспользуются. Я не теоретик.
Ну да, поэтому слова и незарезервированы.
P>А транслятор, если встретит служебное слово, должен анализировать контекст. C++, конечно, тоже. Но если С++ увидит что-то не то, он просто вернет ошибку. А PL/1 будет думать, что ему делать. Не просто так компилятор PL/1 в 6 проходов работал.
Глупости. Структура языка и транслятор устроены жестко: все кроме метки и присваивания должно начинаться с ключевого слова, поэтому неоднозначностей не возникает. И если что-то не то, то и транслятор PL/1 также возвращает ошибку.
Здравствуйте, кт, Вы писали:
кт>Тогда в чем разница между зарезервированными и незарезервированными?
По-моему, гораздо удобнее, когда служебные слова языка можно использовать только как таковые. Я думал, это очевидно любому, кто читал чужой код.
кт>Ну да, поэтому слова и незарезервированы.
Чтобы говнокод плодить? Его и так достаточно.
кт>Глупости. Структура языка и транслятор устроены жестко: все кроме метки и присваивания должно начинаться с ключевого слова, поэтому неоднозначностей не возникает. И если что-то не то, то и транслятор PL/1 также возвращает ошибку.
Служебного слова. Ключевых в Pl/1 нет. Идентификатор вполне может иметь имя, совпадающее со служебным словом. Как и метка. И вот тогда начинаются неоднозначности. Об этом еще в годы, когда PL/1 был популярен, многие писали. И ладно бы просто так писали. Ведь по следам разбора такого кода. В то время только по распечаткам, да с маркером в руках. Это сегодня хорошая IDE может отличить, как используется слово: как служебное или как идентификатор. Но в случае с Фортраном или PL/1 трудоемкость такого анализа слишком высока. В Фортране раньше хоть метки только числовые были.
Здравствуйте, Privalov, Вы писали:
P>По-моему, гораздо удобнее, когда служебные слова языка можно использовать только как таковые.
Но при этом нужно сохранять возможность каким-то (помеченным) образом задавать идентификаторы, совпадающие с ключевыми словами. Во всех более-менее адекватных современных языках такое есть (C#: @if, Rust: r#if, Swift: `if`, Erlang: 'if', Go: экспортируемые идентификаторы с заглавной буквы, и так далее).
C, C++, Java в этом смысле образец подходов допотопья.
А ещё полезно альтернативный вариант пометок использовать для служебных слов, которые вводятся экспериментально или имеют смысл только в специфических контекстах.
P> Я думал, это очевидно любому, кто читал чужой код.
Не совсем. Могут использоваться другие меры, а можно просто писать так, чтобы не абьюзить фичу попусту.
Переименовать внутренние идентификаторы (внутри процедуры/функции/модуля) тривиально. Остаётся крошечная часть внешних.
кт>>Ну да, поэтому слова и незарезервированы. P>Чтобы говнокод плодить? Его и так достаточно.
Для легаси. Вон в C++ ввели co_await. А если у кого-то такое в библиотеке было, всё срочно переименовывать?
P>Служебного слова. Ключевых в Pl/1 нет. Идентификатор вполне может иметь имя, совпадающее со служебным словом. Как и метка. И вот тогда начинаются неоднозначности. Об этом еще в годы, когда PL/1 был популярен, многие писали. И ладно бы просто так писали. Ведь по следам разбора такого кода. В то время только по распечаткам, да с маркером в руках. Это сегодня хорошая IDE может отличить, как используется слово: как служебное или как идентификатор. Но в случае с Фортраном или PL/1 трудоемкость такого анализа слишком высока. В Фортране раньше хоть метки только числовые были.
В Фортране из-за парсинга пробелов чудеса веселее, ты в курсе
Здравствуйте, Privalov, Вы писали:
P>А еще 4 типа управленния памятью: CONTROLLED, AUTO, BASED и STATIC. Это мне помогло с указателями разобраться. В Сях тема не самая простая.
В Сях эта тема очень простая. Вот когда в С++ появляются ссылки тема от стандарта к стандарту усложняется.
P>Но PL/1 свою роль в развитии ВТ уже сыграл.
+1
P>И вот тогда начинаются неоднозначности. Об этом еще в годы, когда PL/1 был популярен, многие писали. И ладно бы просто так писали. Ведь по следам разбора такого кода. В то время только по распечаткам, да с маркером в руках. Это сегодня хорошая IDE может отличить, как используется слово: как служебное или как идентификатор. Но в случае с Фортраном или PL/1 трудоемкость такого анализа слишком высока. В Фортране раньше хоть метки только числовые были.
Сказки. Какой там разбор с маркером? Какие там 6 проходов? Кстати, проходов нужно всего два: сначала только описания, затем все кроме описаний. Из-за того, что описания могут быть и до и после использования.
А с маркером разбирали "однострочники" на APL.
Критика была из-за только одних круглых скобок. X(I)- непонятно, массив с индексом или подпрограмма с параметром. Так это во многих языках.
А незарезервированные слова в реальном коде разбору совершенно не мешают. Ну покажите реальное затруднение при чтении. Везде приводится только идиотская шутка типа:
if if=then then then=else; else if=then;
но к реальным кодам это не имеет отношения. А для транслятора и это выражение не требует сложного разбора.
Здравствуйте, Privalov, Вы писали:
P>Плюс сложности PL/1 доьавляет отсутствие зарезервированных слов. Я как-ьл видел код, когда человек рядом с оператором FORMAT ставил метку FORMAT. А можно ведь и дальше пойти.
Это не сложность языка, а недооценка его создателями банальных сейчас истин, что синтаксис и семантика языка не должны провоцировать на ошибки и неоднозначности. К этому начали приходить через несколько лет.
Сложность PL/1 в том что в него напихали все, что к тому времени было достигнуто в разработке ЯВУ. Причина сложности в его несистемности.
Здравствуйте, pagid, Вы писали:
P>Сложность PL/1 в том что в него напихали все, что к тому времени было достигнуто в разработке ЯВУ. Причина сложности в его несистемности.
И обычный набор инструментов (в смысле железок) тоже "несистемен". Хотя отвертку можно использовать и как шило и как долото Пресловутая "ортогональность" и "системность" объективно противоречат многообразию задач и предметных областей. Когда в языке есть только одно средство и даже только один подход (например плюс — склейка строк и сложение чисел), это может вызывать большие, а не меньшие трудности.
"Когда в руке молоток — все вокруг кажется гвоздями" (с)
Здравствуйте, netch80, Вы писали:
N>Переименовать внутренние идентификаторы (внутри процедуры/функции/модуля) тривиально. Остаётся крошечная часть внешних.
Это сегодня тривиально. Во времена расцвета PL/1 это была та еще задачка. Особенно, если не было ничего, кроме IEBUPDTE. Primus или xEdit, конечно, процесс ускоряли, но это всего лишь редакторы текста.
N>Для легаси. Вон в C++ ввели co_await. А если у кого-то такое в библиотеке было, всё срочно переименовывать?
Я один раз на идентификатор this в сишном коде нарвался, когда пытался его в плюсовом проекте использовать. Давно это было. Но там вылечилось все запретом использовать С++ для компиляции С-кода.
N>В Фортране из-за парсинга пробелов чудеса веселее, ты в курсе
Да, Фортран, как правило, пробелы игнорировал, но не всегда. Я, набивая код даже на перфокартах, на пробелах никогда не экономил, поэтому сам на эти грабли не нарывался. Но у кого-то раз нашел что-то из этой серии. Тогда тетки кричали, что компилятор неправильный. А я молодой, опыта ноль, зато ЧСВ — дальше некуда. Мне повезло тогда, я теткам ошибку указал.
Но вообще именно для Фортрана я видел больше всего объяснений, какие в нем бывают грабли и как их обходить. И старшие товарищи кое-чему научили.
Здравствуйте, кт, Вы писали:
кт>Сказки. Какой там разбор с маркером? Какие там 6 проходов? Кстати, проходов нужно всего два: сначала только описания, затем все кроме описаний. Из-за того, что описания могут быть и до и после использования.
С обыкновенным маркером. Желтым, зеленым. Полторы тысячи строк на PL/1 в распечатанном виде — это до фига. Особенно если идентификаторы в нем написаны по-грузински. Я писал как-то. И мне с таким пришлось разбираться когда-то. Мой первый выговор. Вот и запомнил.
кт>А незарезервированные слова в реальном коде разбору совершенно не мешают. Ну покажите реальное затруднение при чтении. Везде приводится только идиотская шутка типа: кт>
if if=then then then=else; else if=then;
кт>но к реальным кодам это не имеет отношения. А для транслятора и это выражение не требует сложного разбора.
Шутка, может, и идиотская, но основания для нее более чем реальные. Сегодня важно, чтобы текст программы нормально читался человеком. И без зарезезвированных слов в реальном коде встречается достаточно много конструкций, подобных этой шутке.
Здравствуйте, AleksandrN, Вы писали:
AN>ТурбоПаскаль, а позднее ObjectPascal и Delphi Борланд продолжал рекламировать. Как и свои инструменты разработки на C++. Но после короткого и быстрого взлёта, популярность средств разработки Борланда быстро упала и Борланд продала их Embarcadero. Но по опыту использования продуктов Борланд, думаю дело не только в рекламе. Продукты конкурентов оказались лучше.
Да нифига не лучше, отличные у них были продукты. Но цена как была конской, так и осталась, в то время как конкуренты просили меньше, а сейчас уже все либо бесплатные, либо довольно бюджетные.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, pagid, Вы писали:
P>В Сях эта тема очень простая. Вот когда в С++ появляются ссылки тема от стандарта к стандарту усложняется.
Теперь и я так думаю. А в то время сбивали с толку публикации, в которых утверждалось: массивы и указатели – это одно и то же. При нулевом опыте такое проглатывалось. Или я встречал утверждение: такое объявление: int a[2] резервирует память для трех элементов. Пока пару раз память не расстрелял, не доходило.
Здравствуйте, Vain, Вы писали:
V>>>Подготовку программистов для чего, для вакуума? BFE>>Научные вычисления занимают менее процента работы всех программистов. V>Программистов матлаба? 100% занимают.
Здравствуйте, netch80, Вы писали: N>Ссылка на обширный сайт без точного адреса (и даже не на сайт! на слова, по которым его искать) — это не ответ, больше похоже на уход от ответа. Так и запишем.
Да там всё просто. Человек должен мочь прочесть текст вслух.
Тот же самый эффект, как с навигацией в чужой стране: если вы знаете алфавит хотя бы на таком уровне, чтобы прочесть название улицы на указателе вслух, то вы сориентируетесь.
Не обязательно понимать сами слова — по крайней мере вы сможете понять "о, вот моя станция метро, надо выходить", или "ага, туда надо ехать по belred road, потом свернуть на microsoft way".
Знания латиницы достаточно, чтобы успешно навигироваться в городах западноевропейской цивилизации.
В Греции — уже сложнее; если есть университетское образование, то можно напрячься и вспомнить все эти пи, ро, сигмы и прочее — и тоже начать навигироваться.
Грузия? Тайланд? Индонезия? Япония? Без дублирующих надписей латиницей европеец там беспомощен.
Ровно поэтому — навык чтения означает возможность быстрого восприятия, а также поиска сходств и различий.
И ровно поэтому C-style синтаксис так популярен: это lingua franca для большинства программистов. Человек с C++ бэкграундом может сходу читать JSON.
Ключевые слова подходят ровно до тех пор, пока они записаны знакомыми буквами. Соответствуют ли они каким-то словам естественного языка — дело десятое. CAR и CDR ничуть не хуже foldr или from where select.
Отсюда делаем простой вывод: кириллические идентификаторы и русскоязычные ключевые слова будут лучше ровно в одном случае: пользователь не владеет латиницей даже на уровне "це-дэ-эр" или "вхере".
Если он запинается об латиницу также, как я об тайский алфавит — тут да, переход на кириллицу его спасёт.
Нужно понимать, что есть и обратная сторона — применимость программ, написанных этим человеком, ограничена кириллической аудиторией.
Их можно выложить на гитхаб, но европейцы и американцы не смогут их даже комментировать, не то что дорабатывать.
То есть мы должны понимать, что мы целимся
А) в аудиторию, которая владеет латиницей катастрофически хуже, чем кириллицей
Б) в написание программ, у которых будет очень короткий жизненный цикл и/или узкий круг маинтенеров.
То есть что-то типа "управление контроллером температуры в железнодорожном тоннеле", где мы ожидаем пользователей без высшего образования.
Или "обучение программированию детишек до четвёртого класса", хотя и это уже стремительно сокращается — сейчас у детей английский идёт с первого класса, плюс игры/фильмы/сериалы дают почти одновременное освоение латиницы и кириллицы.
Во всех остальных случаях эффективнее обучить пользователя нормальному языку, совместимому с широкой аудиторией.
Точно так же, что никто в ВУЗах не задуряется переводом операторов дивергенции или ротора на русский язык, или заменой знаков интеграла на какую-то более кириллическую нотацию.
Везде сплошные латинские и греческие буквы, плюс спецсимволы.
Зато формулы, которые пишет русский физик, понятны и американцу, и французу, и китайцу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, okman, Вы писали:
O>Для трех? Как такое может быть?..
Конечно, никак. Но материалы такие я читал. Пруфов у меня нет. Я на бумаге читал, давно. Говорю же, пока память пару раз не расстрелял, не вник.
K&R у меня позже появился.
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Sinclair, Вы писали:
S>>Б) в написание программ, у которых будет очень короткий жизненный цикл и/или узкий круг маинтенеров.
DC>Я сейчас поддерживаю программу, которой больше 10 лет. Написана кириллицей. Майтенеров у неё было человек 15 (до меня). И ничего, фирма работает.
Здравствуйте, AleksandrN, Вы писали:
S>>>Б) в написание программ, у которых будет очень короткий жизненный цикл и/или узкий круг маинтенеров. DC>>Я сейчас поддерживаю программу, которой больше 10 лет. Написана кириллицей. Майтенеров у неё было человек 15 (до меня). И ничего, фирма работает. AN>1C?
Тыз нал.
Причём матейнеров только конфигурации. Самой платформы — это не озвучивается...
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, AleksandrN, Вы писали:
S>>>>Б) в написание программ, у которых будет очень короткий жизненный цикл и/или узкий круг маинтенеров. DC>>>Я сейчас поддерживаю программу, которой больше 10 лет. Написана кириллицей. Майтенеров у неё было человек 15 (до меня). И ничего, фирма работает. AN>>1C?
DC>Тыз нал.
Кроме 1С ничего не припоминается массового с языком программирования на основе кириллицы. Так что угадать не сложно.
DC>Причём матейнеров только конфигурации. Самой платформы — это не озвучивается...
В компании 1C вроде вакансии всегда на C++ были и на своём языке. На чём у них ядро написано, на своём языке или на плюсах?
Здравствуйте, AleksandrN, Вы писали:
AN>В компании 1C вроде вакансии всегда на C++ были и на своём языке. На чём у них ядро написано, на своём языке или на плюсах?
Было на плюсах. Сейчас они пытаются пилиить эклипс. Там, разумеется, java.
Но ребёнок как-то не выходит. От платформы на три версии отстаёт...
