[11:04:04] <ada_ru> (I_vlxy_I) "Я искал в Интернете про то, как можно при программировании совершать меньше ошибок, то есть про надежное программирование. И нашел, что чем проще язык, тем он надежнее. Затем начал искать, а какой язык проще. И так нашел Компонентный Паскаль."
[12:35:29] <ada_ru> (nordwnd) Пацан к успеху шел...
[12:49:27] <ada_ru> (t91x0)  отвечает (I_vlxy_I) на <"Я искал в Интернете…>
Это кто писал?
[13:06:58] <ada_ru> (I_vlxy_I)  отвечает (t91x0) на <Это кто писал?>
https://forum.oberoncore.ru/viewtopic.php?f=127&t=6326&p=106009#p106008
[13:10:06] <ada_ru> (I_vlxy_I) Есть много точек зрения на безопасность. Как видим, есть и такая, где Ада язык весьма не надежный. Как и rust тот же.
[13:10:34] <ada_ru> (I_vlxy_I) Вот Оберон и Go — явно более надёжны!
[13:11:03] <ada_ru> (I_vlxy_I) Компонентный Паскаль
[13:14:46] <ada_ru> (nitrocerber) При определённом подходе самые безопасные языки - это те, к которым нету работающих компиляторов)
[13:14:51] <ada_ru> (nitrocerber) Не навреди, все дела.
[13:29:39] <ada_ru> (I_vlxy_I)  отвечает (nitrocerber) на <При определённом под…>
В этом плане Ада была идеальным языком несколько лет подряд :-)
[13:30:41] <ada_ru> (Максим) Логика от меня ускользает. Ну возьми машину Тюринга, и струячь на ней, что может быть проще?
[13:34:18] <ada_ru> (I_vlxy_I)  отвечает (Максим) на <Логика от меня ускол…>
Ну, типа машина Тьюринга она не простая, а примитивная.
[13:35:21] <ada_ru> (I_vlxy_I) Эпиграф к Oberon language report: “everything should be as simple as it can be but not simpler”
[13:36:55] <ada_ru> (t91x0) Есть ли нечто общее между нелюбовью к Компонентному Паскалю и к Дельфи?
[13:40:25] <ada_ru> (Борис)  отвечает (Максим) на <Логика от меня ускол…>
Зато от меня не ускользает. Алексей умеет отыскать любой удачный повод, чтобы устроить либо небольшой хайп на ровном месте, либо, в особо удачном случае, локальный holly war.
[13:46:05] <ada_ru> (I_vlxy_I)  отвечает (t91x0) на <Есть ли нечто общее …>
Да, ассоциации с паскалем. Не более того .
[13:49:13] <ada_ru> (I_vlxy_I)  отвечает (Борис) на <Зато от меня не уско…>
Это да, я умею.

Однако и тема интересная. Сильно разный подход и идеология.
[16:57:10] <ada_ru> (Sergei) С новым годом.
Кто-то в курсе, на чём запрограммирована та штука, которая сегодня, впервые в истории, прилунилась на заднюю сторону?
[16:57:41] <ada_ru> (Sergei) По поводу надёжности - однозначно коррелирует с мощностью языка темплейтов. Если надо, объясню, почему так думаю.
[16:59:18] <ada_ru> (Sergei) С простотой если и коррелирует, то только обратно.
[17:00:24] <ada_ru> (Sergei) чем больше аспектов проблемы можно отразить в языке, тем больше контроль
[17:02:00] <ada_ru> (Sergei) в надёжность превращается только при условии затраты дополнительных часов на отладку, тестирования и понимание . То есть, чем сложнее взаимосвязь проблемы и программы, тем больше часов разработки -> выше надёжность. Но проблема сложная, конечно.
[17:05:20] <ada_ru> (Sergei) С одной стороны, сверхсложная программа, полностью отражающая предметную область - сверхнадёжна, с другой - ни у кого нет времени, чтобы даже её понять.
[17:06:05] <ada_ru> (Sergei) не говоря уже скомпилировать и отладить
[17:08:02] <ada_ru> (Sergei) Потому проблема нерешабельна, но язык может помочь тем, что визуализирует все взаимосвязи, не скрывая и не загромождая очевидными деталями, и тем самым, позволит более предсказуемо работать со сложными программами. А проблему надёжности он не решает.
[17:23:36] <ada_ru> (Sergei) Конечно, прежде чем пускаться в любые рассуждения по поводу надёжности программ надо оговорить, какое определение надёжности программ мы имеем в виду. По Майерсу - соответствие поведения ожидаемости, тоже не лишено недостатков, но есть ли лучшее? Более того, не ясно - ожидания до выполнения программы или после разбора полётов? Потому как любая программа не надёжна за пределами того, о чём подумали её разработчики.
[17:47:17] <ada_ru> (I_vlxy_I)  отвечает (Sergei) на <Конечно, прежде чем …>
А они вечно фигню всякую думают...
[17:47:24] <ada_ru> (Sergei) Вот взять бы хоть выполнение программы, написанной на языке со сборщиком мусора в ситуации ограниченной памяти. Понятно, что более низкоуровневый подход, экономящий каждый байт будет более надёжен. Но большинство разработчиков подумают об этом только после серьёзного фейла. И вот тут вся проблема - какие потенциальные сбойные ситуации считать важными, а какие - нет.
[17:48:35] <ada_ru> (Sergei) Или вот, рекурсия с неограниченным уровнем. Вроде просто, но не надёжно.
[17:49:13] <ada_ru> (Sergei) Хотя ведь и ожидаемо - то есть фейл, но по Майерсу - всё надёжно, ибо ожидаемо.
[18:01:50] <ada_ru> (Sergei)  отвечает (I_vlxy_I) на <А они вечно фигню вс…>
Фигню или не фигню мы узнаем только post mortem.
[18:02:41] <ada_ru> (Sergei) Может оно и лучше иногда, заниматься фигнёй и в код вообще не лезть. Проблема надёжности она такая.
[18:05:22] <ada_ru> (Sergei) Самая надёжная программа - та, которая не делает ничего, и это вполне ожидаемо.
[18:06:02] <ada_ru> (Sergei) Потому любители надёжности стремяться к минимуму функций всегда.
[18:06:43] <ada_ru> (Sergei) В идеале к 0.
[19:39:35] <ada_ru> (I_vlxy_I)  отвечает (Sergei) на <По поводу надёжности…>
а если в языке вообще шаблонов нема?
[19:41:25] <ada_ru> (t91x0)  отвечает (Sergei) на <С новым годом.
Кто-…>
На китайском.

(извините, не мог удержаться)
[19:43:16] <ada_ru> (I_vlxy_I) думаю плюсы какие-нибудь или си
[19:43:52] <ada_ru> (I_vlxy_I) по крайней мере в китайских self driving в основном с++
[19:56:57] <ada_ru> (I_vlxy_I)  отвечает (Sergei) на <С простотой если и к…>
Смотри, посыл следующий:

Если в ЯП есть всё что требуется для структурного и модульного программирования, то минимизируя его (языка) размер мы получим следующее, очень важное свойство: прикладной программист будет иметь возможность знать этот ЯП целиком и полностью, со всеми нюансами и будет до конца понимать что именно делает программа им, или другим программистом на этом ЯП писанная.

Будет точно и четко понимать как поведет себя программа и комп под управлением этой программы на этом ЯП. Никаких сюрпризов.

Еще разок: постулируется, что у такого ЯП (например КП или Оберона) появляется бесценное свойство ПОЛНОЙ постижимости прикладным программистом.
[19:58:15] <ada_ru> (I_vlxy_I) язык оказывается обозрим и постижим. и это напрямую влияет на надежность всего инструментария (в том числе компилятора), программиста и, в итоге, конечного приложения.
[19:59:03] <ada_ru> (I_vlxy_I) Надеюсь правильно изложил. Если переврал что, тут есть сторонники этого подхода. Например Борис может меня поправить, если я что-то не то написал.
[21:01:49] <ada_ru> (FROL256) » будет иметь возможность знать этот ЯП целиком и полностью
[21:02:06] <ada_ru> (FROL256) есть мнениие что ему это не обязательно )
[21:02:09] <ada_ru> (FROL256) он же прикладной
[21:02:30] <ada_ru> (FROL256) но с компилятором согласен, тут не поспоришь
[21:03:50] <ada_ru> (I_vlxy_I) ну, на практике так красиво конечно не получается. по многим причинам.
[21:25:59] <ada_ru> (I_vlxy_I)  отвечает (FROL256) на <есть мнениие что ему…>
Но весьма желательно. А если полное описание языка занимает 16 страниц, то это ему будет не очень обременительно.
[21:43:14] <ada_ru> (FROL256) но ведь можно сделать подмножество на 16 страниц
[21:43:33] <ada_ru> (FROL256) прикладной программист не должен знать всё, всё обязан знать только главный инженегр
[21:43:58] <ada_ru> (FROL256) то есть как бы если нужно что-то урезать то нет проблем — берём и урезаем
[21:44:05] <ada_ru> (FROL256) в чём поинт сокращать язык то ...
[21:44:45] <ada_ru> (FROL256) ну толко что компилятор проще
[21:53:19] <ada_ru> (FROL256) Я вот к сожалению лично со SPARK не успел ещё познакомиться, но как вы думаете может выступать таким примером урезанного пожмножества языка?
[22:11:55] <ada_ru> (I_vlxy_I)  отвечает (FROL256) на <Я вот к сожалению ли…>
В 16 страниц не уложится. Он сложный!
[22:16:24] <ada_ru> (FROL256) ясно ) может в 64 ?) всего на 1 бит больше
[22:16:29] <ada_ru> (FROL256) ой на 2