Короче, ПЛ/1 и в Европе сильно не любили, не только в СССР
Осмелюсь заметить, что нелюбовь к ПЛ/1 в СССР Вами преувеличена. Во всяком случае, он был куда более любим, чем Кобол. Когда стоял выбор — Фортран или ПЛ/1, то Фортран выбирали, в основном, те, кто к нему привык. Остальным же было ясно, что ПЛ/1 — более современный и продуманный язык.
А вот на вашу эмоциональную реплику в стиле Эллочки-Людоедочки («Кошмарный язык!») ответил разработчик отечественного компилятора ПЛ/1 под платформу Wintel Дмитрий Караваев: «Не поминайте всуе PL/1». И опровергает Ваши слова о «сотне автоматических преобразований типов в другие типы».
Название статьи заставило задуматься о подлинно вечных сайтах. Давайте представим: владелец сайта умер, а его сайт навечно остался в истории человечества. Умершему не надо заботиться об оплате доменного имени и услуг хостинга — об этом позаботится оставшееся в живых человечество. В память о покойном, проявляя гуманизм и человечность.
Если такое явление имело бы место, а Интернет появился бы на заре человечества, то знаете, было бы интересно посмотреть на сайты Архимеда или строителей египетских пирамид, летописца Нестора или моего прадеда…
Один из прародителей «Дракона» — ещё и язык ПРОЛ-2. Вот история про то, как Д.Ю.Караваев создал транслятор ПРОЛ-2 для PC (до этого всё работало на ЕС ЭВМ) и что из этого вышло. В сокращении, взято отсюда: «Права доступа к переменным».
Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.
Для повышения надежности в языке ПРОЛ-2 описание нелокальных переменных должно было включать и права доступа в виде списка имен процедур, которым разрешается к этой переменной обращаться.
Так вот, проверочный транслятор выдал большое число сообщений, что идет обращение к переменным без права доступа. Штатный транслятор давно отлажен и многократно проверен. Таких нарушений он бы просто не пропустил. Откуда в проверенных программах взялись сотни ошибок доступа?
Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в «Буране» две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять доступ переменной из процедуры на соседней БЦВМ. Выключилась одна из проверок.
После выяснения этого даже было совещание. Не столько на тему помарки в трансляторе, сколько на тему технологи разработки. Ведь рассчитывали на что? Что разработчики проанализируют сферу действия каждой переменной и явно и осмысленно укажут множество объектов, которые могут эту переменную читать/писать. А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав — так и быть допишем список, не ругнулся — и так сойдет. В текстах даже нашли издевательские описания нелокальных переменных с пустыми списками, т.е. по правилам языка к ним вообще никто не мог обращаться. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.
Лично я не считаю допустивших это программистов какими-то балбесами, не соблюдающими элементарные правила. Все силы и внимание уходили на разработку самих алгоритмов, отработку их взаимодействия, парирование нештатных ситуаций и т.п. На правила записи уже не хватало ни внимания, ни желания.
А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с доступом все было хорошо.
Вопрос: как права доступа к переменным нарисовать в «Драконе»? А никак. «Дракон» — это про алгоритмы. А права доступа — это про данные.
Да написать-то так можно. но получается потом не по фэншую. Дальше придётся писать проверки типов. И тогда уместно к этому случаю приклеить комментарий, который написали ниже:
Никак без очень дурно пахнущих проверок типов. Как, впрочем, и в динамически типизированном языке, просто эти проверки конкретно для сложения написали за вас.
У нас получается не статическая типизация, а кустарная (вручную написанная) динамическая типизация.
Есть момент, который подрывает веру в статическую типизацию. Допустим, пользователь вводит строковые данные. Эти данные надо обработать функцией «распознать(строка)». Эта функция должна вернуть значение числового типа (если пользователь ввёл число), дату (если введённые данные похожи на дату) или исходную строку (если ничего распознать не удалось). Статически определить такую функцию не получится. Функция должна будет возвратить не только значение, но и типовую переменную, поскольку тип заранее не известен.
соглашение ноль==false, не ноль==true кажется вполне однозначным.
Это кажется.
Возьмём логический тип. Пусть false – это 0. Тогда ~0 (не ноль) — это 0xffffffff или -1 в дополнительном коде. Применяя как операции «&», «|», «^»,, так и операции «&&», «||» мы получаем правильные результаты.
Для числового типа это не так. Возьмём значение 1 и значение 2. И то, и другое — это true. Применив к ним операцию «&» (побитовое «и»), получаем 0, т. е. false. Получается, что true & true равно false. Для операции «^» тоже можно подобрать примеры противоречий.
Этот факт навёл меня на мысль/идею о том, что стоит запретить использование числа 42 в документации к своим проектам. А так как просто хардкодить это число — неинтересно, возникла идея устроить такой вот «конкурс».
А Вы в курсе, что есть язык программирования o42a (статья на Хабре и сайт проекта)? Тогда придётся запретить сам язык из-за его имени. Уж коль пошла такая пьянка, приведу решение задачи на этом языке:
Хочу быть Мозилой! Хочу быть некоммерческой организацией, у которой нет заботушки о хлебе насущном, хочу позволить себе заниматься проектами типа Rust! Очень хочу, честное слово…
Насколько мне известно, в комитете по стандартизации C++ Россию представляли Евгений Александрович Зуев и компания «Интерстрон». Как-то упустил момент передачи эстафетной палочки. «Яндекс» как-то сотрудничает в этом плане с «Интерстроном»?
Этот список (https://cleantalk.org/blacklists) слишком мал. Мой в разы больше. Полагаю, что надо распарсить страницу, на которую ссылка из $_SERVER['HTTP_REFERER'] и выявить, есть ли там ссылка на мой сайт. Если нет, то путь идут в баню.
Рекламируются автосалоны, Интернет-магазины, мебель, школы иностранных языков, онлайн-кинотеатры, средства для повышения потенции, юридические услуги, интим-услуги, онлайн-аптеки и прочая, прочая. Несть им числа. Какое отношение они имеют к моему сайту? Да никакого! Мой сайт вообще о программировании. Если он упомянут на Хабре, то с Хабра приходят посетители с соответствующим $_SERVER['HTTP_REFERER']. Я могу зайти по этой ссылке и найти на этой странице ссылку на свой сайт. А вся перечисленная выше шелуха ссылок на меня не содержит. Какой им смысл так рекламироваться – не понимаю.
IP-адреса этих спам-посетителей, естественно, фиксируются. Но они постоянно меняются: сегодня ты закрыл два десятка, а на следующей неделе они лезут уже с других. Какого-то надёжного способа определения добросовестности посетителя нет. Единственное, что приходит в голову – составить список добропорядочных $_SERVER['HTTP_REFERER'] и использовать его в качестве фильтра.
Было бы интересно услышать, как бороться со спам-посетителями. На своём сайте веду статистику посещений. И там немало «левых» $_SERVER['HTTP_REFERER']: там указаны сайты (на самом деле эти сайты рекламируются!), с которых ко мне просто не может быть переходов. Как бы вот с этим побороться? Они же портят не только записываемое в мой журнал, но и статистику Google Analitycs.
Я, как правило, набираю текст сначала в Word, чтобы выявить глупые описки и ошибки. Это вопрос элементарного уважения к тем, кто будет читать твой текст. Естественно, вставляемый в форму ввода текст будет формально считаться слишком быстро набранным.
А вот на вашу эмоциональную реплику в стиле Эллочки-Людоедочки («Кошмарный язык!») ответил разработчик отечественного компилятора ПЛ/1 под платформу Wintel Дмитрий Караваев: «Не поминайте всуе PL/1». И опровергает Ваши слова о «сотне автоматических преобразований типов в другие типы».
Если такое явление имело бы место, а Интернет появился бы на заре человечества, то знаете, было бы интересно посмотреть на сайты Архимеда или строителей египетских пирамид, летописца Нестора или моего прадеда…
кодакниг Кернигана, Ритчи, Страуструпа & etc.У нас получается не статическая типизация, а кустарная (вручную написанная) динамическая типизация.
Это кажется.
Возьмём логический тип. Пусть false – это 0. Тогда ~0 (не ноль) — это 0xffffffff или -1 в дополнительном коде. Применяя как операции «&», «|», «^»,, так и операции «&&», «||» мы получаем правильные результаты.
Для числового типа это не так. Возьмём значение 1 и значение 2. И то, и другое — это true. Применив к ним операцию «&» (побитовое «и»), получаем 0, т. е. false. Получается, что true & true равно false. Для операции «^» тоже можно подобрать примеры противоречий.
Вывод: между типами int и bool разница есть.
IP-адреса этих спам-посетителей, естественно, фиксируются. Но они постоянно меняются: сегодня ты закрыл два десятка, а на следующей неделе они лезут уже с других. Какого-то надёжного способа определения добросовестности посетителя нет. Единственное, что приходит в голову – составить список добропорядочных $_SERVER['HTTP_REFERER'] и использовать его в качестве фильтра.