Pull to refresh
10
0
Send message
А типы слева это как раз одна из главных ошибок С подобных языков, которые ломают им всю логику парсера.
Не могли бы привести аргументы, как происходит эта ломка? Какие трудности возникают у парсера?
функция: f: ℕ -> ℕ — имя, потом «тип аргумента», потом «возвращаемый тип»

y = f(x)	// вызов функции f

Где тут находится возвращаемое? Возвращаемое находится слева! Значит, и при объявлении функции возвращаемое должно находится слева. Зачем нам такой стиль, что результат надо смотреть то слева, то справа? Надо придерживаться одного стиля. Либо справа налево:
тип f(тип)	// объявление
y = f(x)	// вызов
либо слева направо:
f(тип)	-> тип	// объявление
f(x) => y	// вызов
И трижды, и четырежды платит скупой. Но изначально как выглядит? Нам нужно построить некий бизнес-процесс. Какую платформу выбираем? 1С! Это ж почти стандарт по нашей стране. Запилили, всё работает, претензий нет ни по функциональности, ни по производительности. Потом идёт развитие, добавляем и то, и сё, база данных растёт, всё начинает тормозить, появляются глюки. Заказчик недоволен. Разработчик отвечает: «А что ж Вы хотели? Сервер уже не тянет. Посмотрите сами, дисковая подсистема работает зачастую близко к 100% от своих возможностей. Пора покупать новый сервер, старый устарел». Заказчик покупает новый сервер. Проблема уходит, заказчик убеждается, что разработчик был прав. Поэтому когда заказчик дозаказывает новую функциональность, то он уже готов к новым расходам на оборудование.

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

Но реальные факты из жизни говорят, что такое имеет место быть. Как говорит одесская пословица, если проблему можно решить за деньги, то это не проблема, а расходы. Вот заказчик/собственник и решает, что дешевле — то ли новый сервер купить, то ли выкинуть старое ПО и написать заново новое.
Да, порою оказывается так, что дешевле купить новый сервер, который переварит некоторую неэффективность, чем платить программистам за долгую и кропотливую разработку.

А ещё бывает так, что со временем база данных выросла и сервер начинает тормозить. Вы думаете, из той же 1С начинают выковыривать SQL-операторы и заменять на что-то более шустрое? Я вас умоляю! Просто покупают новый сервер. А бывает, что разработка ещё не закончилась, а уже все согласны купить новый сервер. Потому что так сказали головастые мужики. А неголовастым и возразить нечего.
В начале 1970-х Килдалл разработал язык программирования PL/M, Programming Language for Microcomputers. Он был основан на достаточно популярном в те годы PL/1.
К этому можно добавить, что компилятор Килдалла не брошен. Его в течение не одного десятка лет дорабатывал Дмитрий Юрьевич Караваев, пройдя путь от DOS 1.0 до Win-64. И теперь, по его словам, от исходного компилятора не осталось ни одной машинной команды.
Не расстраивайтесь, что Ваша специальность — САПР. Мишустин тоже получил эту специальность. Наверное, тоже баллов не хватило.
Охренеть! Как же на одномоторном самолёте АН-2 могло отказать 2 (два!) двигателя? Или в салоне валялся второй, запасной. И после отказа первого его быстренько, прямо в полёте поставили на место первого, но и он не заработал?
Знаю пример, когда человек, закончивший Иоанно-Богословский православный университет по специальности «религиоведение», в 35 лет стал программистом :)
Короче, ПЛ/1 и в Европе сильно не любили, не только в СССР
Осмелюсь заметить, что нелюбовь к ПЛ/1 в СССР Вами преувеличена. Во всяком случае, он был куда более любим, чем Кобол. Когда стоял выбор — Фортран или ПЛ/1, то Фортран выбирали, в основном, те, кто к нему привык. Остальным же было ясно, что ПЛ/1 — более современный и продуманный язык.

А вот на вашу эмоциональную реплику в стиле Эллочки-Людоедочки («Кошмарный язык!») ответил разработчик отечественного компилятора ПЛ/1 под платформу Wintel Дмитрий Караваев: «Не поминайте всуе PL/1». И опровергает Ваши слова о «сотне автоматических преобразований типов в другие типы».
Название статьи заставило задуматься о подлинно вечных сайтах. Давайте представим: владелец сайта умер, а его сайт навечно остался в истории человечества. Умершему не надо заботиться об оплате доменного имени и услуг хостинга — об этом позаботится оставшееся в живых человечество. В память о покойном, проявляя гуманизм и человечность.

Если такое явление имело бы место, а Интернет появился бы на заре человечества, то знаете, было бы интересно посмотреть на сайты Архимеда или строителей египетских пирамид, летописца Нестора или моего прадеда…
но в чем профит — непонятно.
Профит в повторном использовании кода книг Кернигана, Ритчи, Страуструпа & etc.
Да, переехали на Яндекс. Но не почта, а аккаунты. А вот почта, накопленная за многие годы, исчезла. Первое письмо в «новой» жизни — от 9 декабря с.г.
Один из прародителей «Дракона» — ещё и язык ПРОЛ-2. Вот история про то, как Д.Ю.Караваев создал транслятор ПРОЛ-2 для PC (до этого всё работало на ЕС ЭВМ) и что из этого вышло. В сокращении, взято отсюда: «Права доступа к переменным».
Часть транслятора была написана на ассемблере и поэтому летал он ласточкой.
Для повышения надежности в языке ПРОЛ-2 описание нелокальных переменных должно было включать и права доступа в виде списка имен процедур, которым разрешается к этой переменной обращаться.

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

            Но разбирательство показало, что таки-да, в штатном трансляторе помарка. Вероятно, она проникла в транслятор, когда выяснилось, что ресурсов одной БЦВМ не хватает и приняли решение поставить в «Буране» две машины, разделив ПО между ними. Транслятор подправили для двух ЭВМ, но он перестал проверять доступ переменной из процедуры на соседней БЦВМ. Выключилась одна из проверок.

            После выяснения этого даже было совещание. Не столько на тему помарки в трансляторе, сколько на тему технологи разработки. Ведь рассчитывали на что? Что разработчики проанализируют сферу действия каждой переменной и явно и осмысленно укажут множество объектов, которые могут эту переменную читать/писать. А что получилось в реальности? Разработчики чихали на анализ и совали свои модули в транслятор. Ругнулся он по поводу прав — так и быть допишем список, не ругнулся — и так сойдет. В текстах даже нашли издевательские описания нелокальных переменных с пустыми списками, т.е. по правилам языка к ним вообще никто не мог обращаться. И при этом все работало нормально и казалось, что защита от порчи «чужих» данных хорошо обеспечена.

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

            А что, разве при отработке не было случаев, когда один процесс портил переменную другому процессу? Конечно, были. Только во всех этих случаях как раз с доступом все было хорошо.
Вопрос: как права доступа к переменным нарисовать в «Драконе»? А никак. «Дракон» — это про алгоритмы. А права доступа — это про данные.
Да написать-то так можно. но получается потом не по фэншую. Дальше придётся писать проверки типов. И тогда уместно к этому случаю приклеить комментарий, который написали ниже:
Никак без очень дурно пахнущих проверок типов. Как, впрочем, и в динамически типизированном языке, просто эти проверки конкретно для сложения написали за вас.

У нас получается не статическая типизация, а кустарная (вручную написанная) динамическая типизация.
Есть момент, который подрывает веру в статическую типизацию. Допустим, пользователь вводит строковые данные. Эти данные надо обработать функцией «распознать(строка)». Эта функция должна вернуть значение числового типа (если пользователь ввёл число), дату (если введённые данные похожи на дату) или исходную строку (если ничего распознать не удалось). Статически определить такую функцию не получится. Функция должна будет возвратить не только значение, но и типовую переменную, поскольку тип заранее не известен.
соглашение ноль==false, не ноль==true кажется вполне однозначным.

Это кажется.

Возьмём логический тип. Пусть false – это 0. Тогда ~0 (не ноль) — это 0xffffffff или -1 в дополнительном коде. Применяя как операции «&», «|», «^»,, так и операции «&&», «||» мы получаем правильные результаты.

Для числового типа это не так. Возьмём значение 1 и значение 2. И то, и другое — это true. Применив к ним операцию «&» (побитовое «и»), получаем 0, т. е. false. Получается, что true & true равно false. Для операции «^» тоже можно подобрать примеры противоречий.

Вывод: между типами int и bool разница есть.
Столько копий было сломано. А ведь достаточно было просто обратить внимание на метки:
Метки:
c++
c++20
1 апреля
Этот факт навёл меня на мысль/идею о том, что стоит запретить использование числа 42 в документации к своим проектам. А так как просто хардкодить это число — неинтересно, возникла идея устроить такой вот «конкурс».
А Вы в курсе, что есть язык программирования o42a (статья на Хабре и сайт проекта)? Тогда придётся запретить сам язык из-за его имени. Уж коль пошла такая пьянка, приведу решение задачи на этом языке:
Use namespace 'Console'
@Main (
  Print "42" nl
)
«И наплевать нам, чья берет в борьбе мерзавцев с негодяями». (с) Губерман.

Information

Rating
6,652-nd
Location
Москва и Московская обл., Россия
Registered
Activity