В настоящий момент я на рабочем ноуте под Windows где Gforth я погу запустить под WSL. Но как только я доберусь до своего домашнего десктопа - я обязательно снесу дефолтный .deb пакет и поставлю самый свежий с GitHub.
По теме. Топик можно закрывать. Я вобщем-то выяснил все что хотел.
По моему Java не регламентирует ограничений на объем кода в исходном виде. Хотя существует
лимит в байтах на JVM метод. Там кажется 64килобайта в байткоде.
По поводу тех кейсов когда это приемлемо. В современном проекте бывает кодогенерация.
Это связано с техниками генераторов парсеров (Antlr, JavaCC), или SOAP реализаций.
В этом случае обычно генерируемый код помечается аннотацией @Generated
и как-бы исключается из скоупа разработки. Грубо говоря, мы не желаем смотреть в код
написанный роботом. Мы доверяем этому коду. Но если надо вносить изменения - то меняем
соотв. исходник этой кодогенерации.
По поводу пределов восприятия для обычного модуля (класса) или метода (процедуры).
На лимит модуля кажется Никлаус Вирт ставил ограничение в 4000 строк. А по поводу
метода есть метрики Холстеда (Haltsted) которые буквально в виде числа выводят
сложность метода для человеческого восприятия. Тоесть я-бы исходил не из 30 тысяч
строк а из того насколько сложно (или не сложно) разбираться в этих строках человеку.
Данная задача решается во первых - анализом соседних data-rows. Это можно сделать с помощью оконной функции.
А во вторых... неважно. Решение уже есть. Второе - дело техники.
Другая идея. Я не знаю как работает TrueCrypt. Но допустим это симметричка в режиме ECB. Каждый блок шифруется независимо от другого и нету сцеплений. Размер блока нам известен допустим 4096 байт. Блок файловой системы. И допустим автор сохранил пароль (ключ).
Тогда я предлагаю следующее. Взять создать 2 логических тома которые полностью совпадают с оригинальным по размеру. Зашифровать первый. Сделать дубль на второй. Потом отформатировать первый так-же как и сделал автор. В quick format. После этого у нас есть два одинаковых диска первые из которых с поврежденными блоками.
Теперь если мы сравним их поблочно - то мы знаем что было повреждено.
Миллион раз было в фейсбуке. Писал кому-то что-то умное. И потом скролл-скролл. И капец. Потом ничего не найти. Вобщем этот Цукер-букер сделал соц-сеть с альцгеймером. Я уже в себе стал сомневаться. А вдруг я реально НЕ ПИСАЛ.
ThunderCat, да. Обычно крупные проекты реализуют не одну а множество парадигм и множество точек зрения на разработку. У таких проектов такой длинный lifecycle (видел Java-код которому по 15-20 лет) что меняются архитекторы и изнутри, их код и документация являют собой лоскутное одеяло. Тоесть там - можно найти вообще ВСЁ.
ThunderCat, в современных языках вообще - много фич которые давно отодвинули ООП куда-то
в сторону. Например аннотации и процессинг аннотаций. Аспекты. Это что вообще? Это получается
что есть некая сквозная логика. Или некий скрый flow который программист не писал. Но этот flow
реализован ПОВЕРХ той логики что уже есть.
Или процессор шаблонов в С++. Это - язык в языке. Это - логика которая во время компилляции
встраивается в вашу логику проходя сложные циклы доказательств возможности применения.
Доказываете теорему каждый раз компилируя свой код. На одной из конференций (кажется HiLoad)
один С++ ник утверждал что не доказан останов для этой логики. Тоесть теоретически ваша
компилляция может никогда не закончится.
По теме. Топик можно закрывать. Я вобщем-то выяснил все что хотел.