О безопасности языков программирования

Научно-технические вопросы применения русского языка в программировании. Проекты с сайта программирование-по-русски.рф, кроме ЯОС . Информация об организациях и людях, использующих или изучающих русский язык в программировании. Сравнение операционных систем.
БудДен
Сообщения: 1433
Зарегистрирован: 07.10.18 14:01

О безопасности языков программирования

Сообщение БудДен » 05.01.21 21:42

"написана на более надёжных языках программирования": С "обероном" близко не знаком, но могу заметить, что паскале-подобный синтаксис может отвернуть от себя большую часть отечественных разработчиков, привыкших к группе языков C/C++. В целом-то, понятие "безопасный язык программирования" лично у меня вызывает "деление на ноль", т.к. ЯП никак не отвечает на вопросы безопасности, он — всего лишь инструмент. К нему другие требования, обычно, предъявляются. Тем не менее, было бы замечательно предусмотреть возможность применения и других ЯП.
Факторы надёжности ЯП существуют, и о некоторых даже пишут в учебниках. Коротко:
  • ситуации неопределённого поведения. Например, в Go постановлено, что неинициализированные переменные забиты нулями. В других языках (к сожалению, и в Обероне) они забиты мусором. Соответственно, в голанге такой класс ошибок, как "мусор в памяти" возникнуть либо не может, либо нужны какие-то особые условия для его возникновения. Самый крайний пример - это арифметика. Поскольку в Си не заданы ни размеры в прошлом популярных типов, таких как int, ни поведение при переполнении, сложно написать даже калькулятор. В той же Java заданы и размеры типов, и правила поведения при переполнении.
  • сила типизации. В Си привычно используется void *, некоторые вещи без него сделать просто нельзя. Возникает целый класс ошибок. В Голенге этого нет. В Обероне, в общем-то тоже очень мало, хотя фактически в реализациях оберона зачастую это есть.
  • перегрузка операций. Всем известна проблема JavaScript, что "2"+2="22". Перегрузка операций, или просто чрезмерно гибкое определение операций снижает надёжность языка, поскольку она обезоруживает статическую типизацию, об этом написано и в учебниках
  • адресная арифметика и указатели. В Си, по сути дела, нет массивов. Там есть указатели. Массивы возникают уже на уровне логики программы. Значит, нет способа гарантированно защититься от выхода за пределы массива т.п. В Обероне есть массивы, поэтому там категорически менее вероятна ошибка выхода за пределы массива.
  • автоматическое управление памятью. Недаром Basic, Python, Java и Go нашли своё место под солнцем - благодаря сборке мусора они резко снижают проблемы с висячими указателями.
  • примитивы синхронизации. Некоторые из них, как утверждается, более надёжны, чем другие, хотя тут я не рискну особо выступать
  • мутабельность/иммутабельность. Иммутабельные данные при умеренном применении делают программу более надёжной. К сожалению, в Обероне с этим плохо.
  • уровень сложности языка. Он не должен быть чрезмерным. С++ давно вышел за рамки разумного.
  • неявное определение сущностей. В Баш есть ужасное правило, по которому любая переменная существует (его можно отменить, но на практике этим никто не пользуется).

БудДен
Сообщения: 1433
Зарегистрирован: 07.10.18 14:01

Re: О безопасности языков программирования

Сообщение БудДен » 05.01.21 21:46

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

MihalNik
Сообщения: 164
Зарегистрирован: 05.11.18 11:02

Re: Очередной "манифест"

Сообщение MihalNik » 06.01.21 12:01

КротОзёр писал(а):
06.01.21 01:18
В конечном итоге — это больше дело вкуса. Найти, к чему придраться у языка, всегда можно. Тем более, Си является достаточно гибким и универсальным языком, если его корректно применять.
Дело вкуса - это отсутствие порядка. Придираются же всегда к тому, что взято "с потолка". Брейнфак тоже универсальный язык - тут не к чему придраться. Но применять его, тем более корректно, очень трудоемко. И Си применять тоже трудоемко. Да, легче чем ассемблер, костылями над которым он является. Поэтому люди перешли с машинокода на ассемблер. Поэтому перешли с ассемблера на Си. Поэтому не пишут на Сях, а генерируют исходники из своих ЯВУ, на которых писать, читать и проверять намного легче. Являются ли Си достаточно гибким языком? Тут либо бессмысленное дублирование универсальности, либо нужно говорить о минимальном радиусе изгиба, который у Сей великоват.

Аватара пользователя
КротОзёр
Сообщения: 41
Зарегистрирован: 05.01.21 02:16

Re: Очередной "манифест"

Сообщение КротОзёр » 06.01.21 13:05

MihalNik писал(а):
06.01.21 12:01
Дело вкуса - это отсутствие порядка. Придираются же всегда к тому, что взято "с потолка". Брейнфак тоже универсальный язык - тут не к чему придраться. Но применять его, тем более корректно, очень трудоемко. И Си применять тоже трудоемко. Да, легче чем ассемблер, костылями над которым он является. Поэтому люди перешли с машинокода на ассемблер. Поэтому перешли с ассемблера на Си. Поэтому не пишут на Сях, а генерируют исходники из своих ЯВУ, на которых писать, читать и проверять намного легче. Являются ли Си достаточно гибким языком? Тут либо бессмысленное дублирование универсальности, либо нужно говорить о минимальном радиусе изгиба, который у Сей великоват.
Один из инструментов. Для меня, например, C/C++ — достаточно гибкий и функциональный, причём более удобный в применении, чем языки, основанные на PASCAL-е подобном синтаксисе. А, учитывая тематику сайта, стек C/C++ на текущий момент повинен лишь в том, что не имеет себе подобной русской альтернативы. Как, в общем-то, и Оберон.

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

MihalNik
Сообщения: 164
Зарегистрирован: 05.11.18 11:02

Re: Очередной "манифест"

Сообщение MihalNik » 06.01.21 14:07

КротОзёр писал(а):
06.01.21 13:05
стек C/C++ на текущий момент повинен лишь в том, что не имеет себе подобной русской альтернативы. Как, в общем-то, и Оберон.
Стек С/++ ни в чем не повинен. Как и Оберон. Они решают свои задачи.
Русификация первого давно существует. Автор сайта делает русификацию второго, потому что это ближе к его задачам (единоличного управления), а не потому что он любит его синтаксис. Синтаксис он любит вообще от лиспа.
Но все они не предназначены для русскоязычного программирования изначально.
Потому что требования народа к русскоязычному программированию это не требования к С/++/Оберону.
Есть общее предложение ввести кириллицу в синтаксис и логику языков программирования, получив тем самым свои, независимые языки.
Кириллица не создает новые языки и логики не касается.

Аватара пользователя
КротОзёр
Сообщения: 41
Зарегистрирован: 05.01.21 02:16

Re: Очередной "манифест"

Сообщение КротОзёр » 06.01.21 17:05

MihalNik писал(а):
06.01.21 14:07
Кириллица не создает новые языки и логики не касается.
Кириллица закладывает правила ветвления понятийного аппарата документации к языку, которая уже строится от архитектуры. В английском языке есть понятия, отсутствующие в русском, а потому они трудны для восприятия. Проект GNU не зря начинал именно со средств разработки.

Аватара пользователя
КротОзёр
Сообщения: 41
Зарегистрирован: 05.01.21 02:16

Re: О безопасности языков программирования

Сообщение КротОзёр » 06.01.21 17:48

БудДен писал(а):
05.01.21 21:42
ситуации неопределённого поведения. Например, в Go постановлено, что неинициализированные переменные забиты нулями. В других языках (к сожалению, и в Обероне) они забиты мусором. Соответственно, в голанге такой класс ошибок, как "мусор в памяти" возникнуть либо не может, либо нужны какие-то особые условия для его возникновения. Самый крайний пример - это арифметика. Поскольку в Си не заданы ни размеры в прошлом популярных типов, таких как int, ни поведение при переполнении, сложно написать даже калькулятор. В той же Java заданы и размеры типов, и правила поведения при переполнении.
Потому, как принудительная инициализация по стандарту тратит исполнительное время приложения впустую. Особенно, если, скажем, структура создаётся как буфер, а потому после инициализации предстоит побайтовое копирование данных в неё. Насколько это влияет на скорость исполнения, могу сказать как в недавнем прошлом разработчик ГИС. Влияет, и ещё как. Мешает проходить временной норматив обработки, заложенный в ТЗ.
БудДен писал(а):
05.01.21 21:42
сила типизации. В Си привычно используется void *, некоторые вещи без него сделать просто нельзя. Возникает целый класс ошибок. В Голенге этого нет. В Обероне, в общем-то тоже очень мало, хотя фактически в реализациях оберона зачастую это есть.
Универсальный указатель — проблема? Это тогда надо менять архитектуру самих ЭВМ, чтобы избавиться от его применения.
БудДен писал(а):
05.01.21 21:42
перегрузка операций. Всем известна проблема JavaScript, что "2"+2="22". Перегрузка операций, или просто чрезмерно гибкое определение операций снижает надёжность языка, поскольку она обезоруживает статическую типизацию, об этом написано и в учебниках
Перегрузка операторов — великая способность языков, без которой ими невозможно адекватно пользоваться. Не стоит их примешивать к "динамическим типам".
БудДен писал(а):
05.01.21 21:42
адресная арифметика и указатели. В Си, по сути дела, нет массивов. Там есть указатели. Массивы возникают уже на уровне логики программы. Значит, нет способа гарантированно защититься от выхода за пределы массива т.п. В Обероне есть массивы, поэтому там категорически менее вероятна ошибка выхода за пределы массива.
Т.е., контейнеры массивов запихнули в парадигму языка, лишив программиста права на свободное приведение типа этого указателя. "Замечательно"...
БудДен писал(а):
05.01.21 21:42
автоматическое управление памятью. Недаром Basic, Python, Java и Go нашли своё место под солнцем - благодаря сборке мусора они резко снижают проблемы с висячими указателями.
И благодаря этой же "сборке мусора" мне приходится минимум раз в неделю перезагружать коммуникатор. Не зря старательно обхожу стороной языки программирования с этим чудовищным механизмом. К тому же, если сборщик мусора — такая замечательная идея, так почему же тогда "не взлетел" язык D? Уж насколько гибкая и красивая парадигма, а сообщество его на заметило. Может дело не в сборщике мусора, а в количестве вливаемых денег в "раскрутку" языка?
БудДен писал(а):
05.01.21 21:42
примитивы синхронизации. Некоторые из них, как утверждается, более надёжны, чем другие, хотя тут я не рискну особо выступать
Они просто имеют разную применимость в разных ситуациях. Проблема "владения" таким примитивам свойственна вообще всем языкам.
БудДен писал(а):
05.01.21 21:42
мутабельность/иммутабельность. Иммутабельные данные при умеренном применении делают программу более надёжной. К сожалению, в Обероне с этим плохо.
Обычная константность. Ничего нового.
БудДен писал(а):
05.01.21 21:42
уровень сложности языка. Он не должен быть чрезмерным. С++ давно вышел за рамки разумного.
Смотря что называть "сложностью". Писать код в Ассемблере — тоже сложно. C++ пытаются сохранять обратно-совместимым с языком Си, что ему и вредит. Это два языка, но сообщество этого понимать не желает. А излишняя "простота" часто именуется термином "дубовость", что само по себе усложняет программирование на таком языке. Это как взять пятипальцевый аккорд шестиструнной гитары на балалайке. В C++ нет устаканенного подхода к стандартным библиотекам, это есть. Тут надо наводить порядок. Парадигма RAII в C++ мешает применять VLA в языке Си. А всё потому, что в C++ не внесли возможностей нормально работать с массивами, не убивая правила типизации. Вот такие недоработки и ведут к усложению. Зачастую "сложность" языка — это либо его ограничения, либо неспособность его понять.
БудДен писал(а):
05.01.21 21:42
неявное определение сущностей. В Баш есть ужасное правило, по которому любая переменная существует (его можно отменить, но на практике этим никто не пользуется).
Там не совсем так. Есть unset, который "убивает" переменную. В целом каждая переменная BASH носит строковой тип. А всё потому, что BASH — никогда не был и не становился языком программирования. Это — командный интерпретатор рабочей среды. Он лишь управляет вызовом других программ или команд. А куда большая проблема — отсутствие полноценной реализации функционала BASH в самих языках программирования. Всё, конечно, можно сделать, но где внятные стандартные библиотеки-то?

Аватара пользователя
КротОзёр
Сообщения: 41
Зарегистрирован: 05.01.21 02:16

Re: О безопасности языков программирования

Сообщение КротОзёр » 06.01.21 17:59

Жаль, что по прошествии лет я не могу воссоздать документацию языка K++, разрабатывавшегося в 2006 году для разработки приложений проекта Deeptown.Org.

Он допускал контейнеризацию исполняемого кода, благодаря чему лямбда-функцию можно было передать внутрь другой функции через аргумент или вернуть по результату исполнения.
Там допускался полиморфизм объектной модели, как в JavaScript.
Разработчики даже задавались вопросом, как лучше интерпретировать значение 0 для чисел типа "integer": как положительное или как отрицательное. Я тогда предлагал ввести особое правило трактовки именно как нуля, что очень помогло бы с теми же указателями.

Один из разработчиков даже блестяще защитил дипломный проект, предъявив этот ЯП на суд комиссии.

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

БудДен
Сообщения: 1433
Зарегистрирован: 07.10.18 14:01

Re: О безопасности языков программирования

Сообщение БудДен » 06.01.21 20:14

Мне приходилось писать существенные куски кода на некотором количестве языков. Машинные кода калькулятора БЗ-34 были моим первым языком. Далее Бейсик, Клиппер, Паскаль (Турбо, а затем Дельфи), SQL (включая языки хранимых процедур для двух серверов), C++ (Qt), Wolfram Mathematica, Common Lisp, tcl. Сейчас вот немного go и совсем капля яваскрипты, явы, питона и окамля. На bash приходится. Также я разрабатывал свой язык года три. Нужно иметь кругозор и именно опыт написания на разных языках. Мне кажется, у Вас кругозора слегка не хватает.

По моей субъективной оценке, добротные языки из тех, с которыми я имел дело - это go, клиппер, Mathematica и common lisp. Второй эшелон - это tcl, ассемблер, sql с хранимками, оберон. Всё остальное - это дерьмо, в общем-то. Это моё субъективное мнение, но основанное на достаточном опыте, на достаточно подробном знакомстве с решениями, принятыми при разработке языков. Эти решения бывают очень разными! Зная только Си и Паскаль, некоторые вещи даже не придут в голову, а они в каких-то языках есть и широко применяются. Да, у меня тоже был период, когда мне нравились шаблоны С++ и прочие такие навороты, но оно прошло очень быстро, потому что мне повезло и я увидел, как на самом деле всё должно выглядеть. У Вас я вижу опыт JavaScript, C++ и SQL. Т.е. возможно, что вы и света-то в жизни не видели.

Я понимаю, что выбор языков программирования - это вопрос почти религиозный. Но это лучшее из того, что я вижу именно для этой задачи. Да, сборка мусора - это не 100% применимая парадигма. Но и задача у нас не на 100% всего мыслимого. Оберон - не идеал, но немаловажно то, что в нём мало всего, его можно доращивать или делать двухслойную конструкцию, где Оберон используется в качестве своего рода ассемблера. А поскольку приложений на нём очень мало, язык можно как угодно курочить.

Я с этого пути не сверну 100%. Даже если и сверну, то языки Си и Си++ для меня - это последнее, чем я готов заниматься. В хобби-режиме заниматься ими не буду, и денег на разработку на этих языках не возьму. На работе приходится иметь с этим дело, но я от этого стараюсь находиться на максимальном удалении, пока удаётся. В конце концов, жизнь коротка и я не готов тратить её на то, что вызывает у меня стойкое отвращение. Если Вы тоже со своего не свернёте, то нам нужно искать другие точки соприкосновения.

Это, так скажем, организационная сторона вопроса. По сути дела, обнуление имеет свою стоимость. Я считаю, что сейчас ключевая проблема России - это отсутствие киберзащищённости, т.е. способность противника перехватить управление нашей инфраструктурой и вести разведку с помощью тотального прослушивания всех коммуникаций и биг даты. Учитывая безалаберность населения, это реально страшно. Умрём ли мы, если у нас будет своя инфраструктура, но с обнулением? Или пусть она будет без обнуления, на 20% быстрее, но решето? Я однозначно выбираю обнуление.

Аватара пользователя
КротОзёр
Сообщения: 41
Зарегистрирован: 05.01.21 02:16

Re: О безопасности языков программирования

Сообщение КротОзёр » 06.01.21 21:30

БудДен писал(а):
06.01.21 20:14
У Вас я вижу опыт JavaScript, C++ и SQL.
Ну да, я скрываю часть навыков.
Assembler, C, C++ (как с Qt, так и без), немного C#, немного Java, GW-Basic/QBasic/TBasic, немного VBA, немного 1C, TPascal-5/7, Object Pascal, SQL, PHP, JavaScript, TypeScrypt, немного Perl, немного Lisp, немного Prolog+Erlang.
В итоге остановился на C/C++. С ними работать в целом удобнее.

Ответить