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

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

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

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

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

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

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

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

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

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

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

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

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

Аватара пользователя
КротОзёр
Сообщения: 54
Зарегистрирован: 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
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

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

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

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

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

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

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

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

Аватара пользователя
КротОзёр
Сообщения: 54
Зарегистрирован: 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 в самих языках программирования. Всё, конечно, можно сделать, но где внятные стандартные библиотеки-то?

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

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

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

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

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

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

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

БудДен
Сообщения: 2839
Зарегистрирован: 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% быстрее, но решето? Я однозначно выбираю обнуление.

Аватара пользователя
КротОзёр
Сообщения: 54
Зарегистрирован: 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++. С ними работать в целом удобнее.

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

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

Сообщение БудДен » 06.01.21 21:38

Очено коротко ещё по техническим пунктам. Обнуление должно быть умолчанием, но если скорость этого требует, то можно делать как-нибудь

Код: Выделить всё

перем данные = МУСОР : ряд 10050 из литера8
Т.е. отсутствие обнуления явно указывается инициализатором. Также я всё же писал о факторах надёжности языков. А понятно, что если мы одно лечим, то другое калечим. Надёжность чего-то стоит.

То же и про сборку мусора - она увеличивает надёжность, D не взлетел, но ява, дотнет, го, Ruby, PHP, Python уж точно взлетели. Лисп как взлетел, так по сей день и летит - ведь EMACS на нём написан, да и в PostgreSQL, и в gcc в родословной лисп тоже прослеживается. Также ocaml, haskell и ещё куча всего.

Универсальный указатель - да, это проблема надёжности. Как раз для того, чтобы было безопаснее, и создаются ЯП со строгой типизацией. void * нужен по той причине, что выразительность Си недостаточна. В С++ с этим получше.

> Т.е., контейнеры массивов запихнули в парадигму языка, лишив программиста права на свободное приведение типа этого указателя
Это совершенно нормально. В Обероне есть адресная арифметика, которая помечается необходимостью импорта в таком модуле псевдомодуля SYSTEM (НИЗКОУР). Как правило, нужны массивы, а адресная арифметика - лишь иногда. В Си нет массивов, а только адресная арифметика. В Си люди вынуждены пользоваться опасным ввиду отсутствия безопасного.

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

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

Сообщение БудДен » 06.01.21 21:45

Если мы делаем систему для кибербезопасности, то мы должны иметь доверенный компилятор. Компилятор в A2 есть, он содержит примерно 3,5 Мб исходников - это для ARM и AMD. Конечно, он не доверенный, т.к. его нужно для этого очень долго проверять. Но объём кода умеренный, сам язык достаточно простой. Оптимизаций в компиляторе почти никаких нет. Т.е., если взяться за эту работу, то цель получения довереннго компилятора выглядит более-менее достижимой. А как мы получим доверенный компилятор в случае Си/Си++? И доверенный компилятор ЧЕГО нам понадобится? Мы же не будем брать Си/Си++ как он есть - его захочется починить, выкинуть то, что в нём явно кривое, отжившее. Си, понятное дело, не даёт достаточной производительности труда при разработке. Тогда мы окажемся между несколькими стульями, т.к. нам придётся решать, какие приложения не смогут быть скомпилированы нашим компилятором ввиду недостаточности реализаций возможностей языка. Мы втянемся в мучительный поиск компромиссов. Дальше, доверенный компилятор должен быть простым, т.е. наш компилятор будет генерировать очень плохой код по сравнению с gcc. И получится, что язык у нас кудрявый, а производительность кода при этом не особо. Если же мы попробуем реализовать полный современный Си++, то это куча лишней работы, ведь C++ не чистился от мусора, а накопил весь "холестерин" за всю историю компьютерной техники. В принципе сделать компилятор С++ - это огромная задача, а уж доверенный - и подавно.

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

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

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

БудДен писал(а):
06.01.21 20:14
Это, так скажем, организационная сторона вопроса. По сути дела, обнуление имеет свою стоимость. Я считаю, что сейчас ключевая проблема России - это отсутствие киберзащищённости, т.е. способность противника перехватить управление нашей инфраструктурой и вести разведку с помощью тотального прослушивания всех коммуникаций и биг даты. Учитывая безалаберность населения, это реально страшно. Умрём ли мы, если у нас будет своя инфраструктура, но с обнулением? Или пусть она будет без обнуления, на 20% быстрее, но решето? Я однозначно выбираю обнуление.
В общем-то, C/C++ — одна из причин, почему сейчас работаю на "оборонке", хотя дела в ней в целом идут откровенно паршиво. И язык тут ни при чём. По предпочтениям, я скорее создал бы форк этого стека языков в русском варианте с некоторыми вкраплениями из разных языков. Но решать вопрос безопасности выбором языка — довольно странный метод. Это — как повышать проходимость автомобиля, меняя всю его электропроводку.

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

Вопрос же киберзащищённости я решаю своими методами, не меняя языка.

А что касается "обнуления", если не понимать под этим политическую тему, то в своём коде я это применяю чуть более, чем регулярно. Конструктор обнуляет переменные, причём даже в структурах, деструктор делает это по завершению. Исключением являются рекурсивные процессы, где происходит полная подмена значений переменных — там никакое обнуление не нужно от слова "совсем".

Но, ведь, на всё же есть другая точка зрения?
Не обязательно отталкиваться от бинарной логики вроде:
  • "Ты с нами или против нас?";
  • "Ты за частную собственность на средства производства или против?";
На мой взгляд, не нужно делать обнуления, как обязательной процедуры.
Достаточно учитывать это в компиляторе:
  • Если до чтения переменной она не была инициализирована — инициализировать.
  • Если ситуация не предсказуема (преобразование указателя) — инициализировать.
  • Если первая процедура — запись, то — не инициализировать.
Неужели это не логичнее, чем менять язык?
Опять же упомяну: я никого не заставляю менять предпочтения — они на то и предпочтения.

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

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

Сообщение БудДен » 06.01.21 22:09

Ну, моя программа-максимум была - втянуть Вас в ЯОС, т.к. это самый содержательный проект из всего куста. Но можно искать и другие точки взаимодействия. В общем-то моё "предисловие" включает в себя и критику C/C++ в том числе. Эти языки слишком популярны в нашей военке, причём не в каком-то идеализированном виде, а в том, в каком они есть на практике. Я считаю, что это просто беда. Учитывая, что мы отстаём, мы не можем позволить себе такую низкую производительность труда. Если, допустим, мы подписываемся под этим "предисловием" вместе, то придётся менять текст. Ну т.е. нужно как-то обрабатывать имеющиеся расхождения. Пока что можно зафиксировать, что они есть.

Из проектов в рамках Си/Си++ я могу себе представить такой: взять какую-нибудь маленькую RTOS и перевести её на русский. Но при этом неплохо, чтобы план деятельность включал понимание того, откуда возьмётся доверенный компилятор для такой ОС.

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

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

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

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

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

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

Сообщение MihalNik » 06.01.21 23:40

КротОзёр писал(а):
06.01.21 21:30
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++. С ними работать в целом удобнее.
Это бессмысленно вне контекста задач. Писать/переделывать компиляторы С/++ явно не удобнее.
Но когда устраивают С/++ или другие какие-то готовые решения то и переделывать компиляторы не надо.
Следует все-таки отличать удобство наличия кучи библиотек от собственных вполне измеримых свойств языка.

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

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

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

Сообщение КротОзёр » 07.01.21 00:24

БудДен писал(а):
06.01.21 22:09
Ну, моя программа-максимум была - втянуть Вас в ЯОС, т.к. это самый содержательный проект из всего куста. Но можно искать и другие точки взаимодействия.
В сфере русификации отечественного IT слишком много нерешённых проблем. Очень многое касается тех же рабочих сред и их приложений, а всё это написано на разных языках. Кстати, те же скриптовые интерпретируемые ЯП всё равно потребуются для системно-административных целей. Но проблема куда шире. Она затрагивает даже сферу ВЕБ-программирования, где наметился было позитивный сдвиг, но так и застрял на пол пути. А там применение виртуальных машин и адаптированных к ним ЯП является вполне очевидным решением.
БудДен писал(а):
06.01.21 22:09
В общем-то моё "предисловие" включает в себя и критику C/C++ в том числе. Эти языки слишком популярны в нашей военке, причём не в каком-то идеализированном виде, а в том, в каком они есть на практике. Я считаю, что это просто беда.
Языки C/C++ и близко не идеальны. При разработке русского форка я не стал бы их переносить в своём исходном виде. Совсем иной разговор, что среди новых языков практически ничего не вызывает энтузиазма. В таких языках, как GoLang, Rust я вижу лишь деградацию.
БудДен писал(а):
06.01.21 22:09
Учитывая, что мы отстаём, мы не можем позволить себе такую низкую производительность труда.
Производительность труда зависит не от языков. Среди существующих на рынке проектов ПО слишком много продуктов, написанных без какой-либо оптимизации архитектуры и с повторением уже разработанного кода. Можно сказать, половина мирового IT больше не умеет применять абстракции. А появление "контейнеров" и пакетных форматов "контейнерного" типа явным образом указывает на плачевное состояние дел.
БудДен писал(а):
06.01.21 22:09
Из проектов в рамках Си/Си++ я могу себе представить такой: взять какую-нибудь маленькую RTOS и перевести её на русский. Но при этом неплохо, чтобы план деятельность включал понимание того, откуда возьмётся доверенный компилятор для такой ОС.
FreeRTOS хорошо годится на эту роль. У неё достаточно красивый и аккуратный код. Есть так же системное окружение для "встраиваемых" платформ, BusyBox. Её преимущество — очень малоразмерное, компактное исполнение, повторяющее весь базовый набор POSIX-окружения. С неё удобно начинать полную перекройку философии окружения с выработкой своего стандарта и набора команд.
БудДен писал(а):
06.01.21 22:22
Есть вообще такое направление, как внедрение РЯ в существующие проекты. Я вот на работе пытаюсь это слегка делать, и у меня есть трения с коллегами. Поскольку мне платят не за это, то я более-менее настаиваю лишь на том, чтобы имена веток в гите назывались по русски, и сообщения коммитов тоже. И то это не все выполняют. Некоторые прямо говорят, что скорее уволятся, чем будут делать что-то из того, что я хочу.
А чего Вы ожидали? Программисты — тоже потребители, им свойственен свой эгоизм. Лучше не злите их сильно, а то руководству придётся принимать непопулярные меры. Сама идея РЯ в программировании уже вводит планку сегрегации.
MihalNik писал(а):
06.01.21 23:40
Это бессмысленно вне контекста задач. Писать/переделывать компиляторы С/++ явно не удобнее.
Но когда устраивают С/++ или другие какие-то готовые решения то и переделывать компиляторы не надо.
Следует все-таки отличать удобство наличия кучи библиотек от собственных вполне измеримых свойств языка.
К сожалению, это тоже напрашивается. Главный бардак, он не в языке, а в тех самых библиотеках.

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

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

Сообщение БудДен » 08.01.21 11:44

Вот есть цитатка из MISRA C 1998 года, где написано, что язык Си плохо подходит для систем с высокими требованиями к безопасности и что лучше использовать вместо него Аду или Модулу 2. И это не наше дилетантское или частное мнение, а мнение консорциума, в который входят автомобилестроители, американские НИИ (во всяком случае, один НИИ там точно есть) и производители электроники. Эта цитатка даже была в некоторых версиях "предисловия", но не удержалась при оптимизации по размеру.

Т.е. это, в общем-то, мнение клиента, а клиент всегда прав. Сейчас получилось так, что новые языки всех съели и образовалась монополия. В новых версиях MISRA C этой цитатки, как говорят, уже нет. Но это уже нерыночный фактор. Если мы в России следуем путём догоняющего развития, то наша сила в том, что мы можем учиться на чужих ошибках. Но поскольку в голове карго-культ, то способность учиться на чужих ошибках утрачена. Модула-2 и Ада в принципе никуда не делись, в Аде есть интересные технологии по формальной верификации, такие, как spark. Модула-2 по сей день летает в космосе на Глонассе. Т.е. бери и пользуйся, необязательно жрать кактус.

Я прошу прощения за педалирование этой темы, просто у меня продолжается переписка про Embox, я на него посмотрел и очень разозлился. В целом-то пора давно успокоиться :) При этом я вспомнил этот аргумент. Это хороший аргумент, я его не сразу нашёл. Поэтому он должен прозвучать.

Теперь очевидно, надо найти Misra C++ и почитать, как там его ругают.

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

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

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

А что делать, если ни Ада, ни Модула не по нраву? Даже признание проблем Си проблему-то не решает. Это — как с тем же Питоном: он либо нравится, либо бесит. Не могу понять, чем же вариант разработки другого языка на основе Си плох? Можно учесть ошибки и не нарываться на них.

Аватара пользователя
Лис [Вежливый]
Сообщения: 561
Зарегистрирован: 08.10.18 13:32

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

Сообщение Лис [Вежливый] » 08.01.21 17:31

«чем же вариант разработки другого языка на основе Си плох?»

не ясно, что означает слово "основа" в этом предложении. Если же разрабатывать транслятор другого языка, программируя на языке C, то недостаток такой разработки в том, что надо учить английский язык. Билл Гейтс в разработке рекомендовал ограничиваться единственным языком - родным.
Последний раз редактировалось Лис [Вежливый] 08.01.21 18:20, всего редактировалось 1 раз.

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

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

Сообщение MihalNik » 08.01.21 17:57

КротОзёр писал(а):
08.01.21 17:29
Можно учесть ошибки и не нарываться на них.
Только глагол "учесть" совершенного вида, а "нарываться" - несовершенного.
Постоянно что-то учитывать - это не учесть.
КротОзёр писал(а):
08.01.21 17:29
чем же вариант разработки другого языка на основе Си плох?
Тем, что изначально совершенно не ясно о чем идет речь:
1. Язык транспилируется в си-код?
2. Язык изначально пишется си-кодом?
3. Язык расширяет и поддерживает си-код?
4. Язык содержит какие-то синтаксические конструкции или концепции языка Си?

Так-то есть и реализации Оберона на основе Си.
Поменять синтаксис и вовсе несколько сотен строк кода.

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

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

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

Лис [Вежливый] писал(а):
08.01.21 17:31
«чем же вариант разработки другого языка на основе Си плох?»

не ясно, что означает слово "основа" в этом предложении. Если же разрабатывать транслятор другого языка, программируя на языке C, то недостаток такой разработки в том, что надо учить английский язык. Билл Гейтс в разработке рекомендовал ограничиваться единственным языком - родным.
Основа — это базовые положения языка программирования, а не лексические конструкции.
Его парадигма, синтаксис, правила обработки прекомпилятором.
Естественно не влоб копировать, а лишь лучшее, избавляясь от худшего.
MihalNik писал(а):
08.01.21 17:57
КротОзёр писал(а):
08.01.21 17:29
чем же вариант разработки другого языка на основе Си плох?
Тем, что изначально совершенно не ясно о чем идет речь:
1. Язык транспилируется в си-код?
2. Язык изначально пишется си-кодом?
3. Язык расширяет и поддерживает си-код?
4. Язык содержит какие-то синтаксические конструкции или концепции языка Си?

Так-то есть и реализации Оберона на основе Си.
Поменять синтаксис и вовсе несколько сотен строк кода.
Нет, обратная совместимость тут ни к чему, так что вариант 4.
У языков C/C++ в их текущем варианте очень много недостатков, от которых было бы неплохо избавиться.
А если сразу разрабатывать ЯП русским, так и вовсе нет смысла ограничиваться.

Как пример "оторванного" варианта:

Код: Выделить всё

включить <консоль>;
включить процесс;

применять пространство консоль;
применять класс процесс;

цел 8 начало()
{
    авто арг-ты = программа::аргументы;
    
    // Первый аргумент.
    если(арг-ты.нет(0))
        вывод << "Требуется хотя бы один аргумент!" << вк;;
        возврат 1;
    
    // Разные варианты аргумента.
    выбор(арг-ты[0])
    {
        "запуск"     : если(запущен) останов;; запуск;
        "останов"    : если(запущен) останов;
        по умолчанию : вывод << `Неопознанная команда "арг-ты[0]"!` << вк;; возврат 1;
    }
    
    возврат ожидание;
}
Тут, если присмотреться, сразу куча отличий от C++.

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

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

Сообщение MihalNik » 08.01.21 23:02

КротОзёр писал(а):
08.01.21 20:13
обратная совместимость тут ни к чему, так что вариант 4.
У языков C/C++ в их текущем варианте очень много недостатков, от которых было бы неплохо избавиться.
Тут нужен конкретный перечень проблем, а не оторванные примеры синтаксиса.

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

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

Сообщение БудДен » 08.01.21 23:29

КротОзёр писал(а):
08.01.21 17:29
А что делать, если ни Ада, ни Модула не по нраву? Даже признание проблем Си проблему-то не решает. Это — как с тем же Питоном: он либо нравится, либо бесит. Не могу понять, чем же вариант разработки другого языка на основе Си плох? Можно учесть ошибки и не нарываться на них.
К языку можно привыкнуть. Даже к КЛЮЧЕВЫМ СЛОВАМ КАПСОМ можно привыкнуть, как оказалось. Хотя я при переводе их заменил на мелкие. Если речь идёт о транспиляции, то делать язык на основе Си - это значит резко усложнить стек технологии, в т.ч. снизится комфорт в процессе разработки, надёжность и затруднится отладка. Если о чём-то другом - то нужно конкретизировать, что именно имеется в виду.

Ответить