Мне кажется, чтобы что-то такое выстреливало, нужно какой-то порог эпичности перейти.
Аутентичные консоли брали низкой ценой в регионах, где они становились лучшими за свою цену. В нашем регионе почти у всех есть мобилки. Хотя их не приходится назвать дешёвыми, но просто сейчас трудно найти игорька, у которого бы не было мобилки. А, значит, не очень понятно, как давить ценой.
Другие консоли берут высокой производительностью. Тоже мимо.
Третьи консоли берут ретро-совместимостью. Они дорогие, но на них что-то старое хорошо работает. Это ITX-Llama, x86 ретро-ПК с ISA DMA звуковой картой и встроенной эмуляцией Roland MT-32. Ещё как горячие пирожки разлетелась Apollo A6000, клон Амиги в механической клавиатуре.
EverCade подкупает тем, что игры у них лицензионные. Под наши консоли, кажется, нескоро начнут портировать как под EverCade. У нас вообще в России свои разработчики старых игр есть, можно вспомнить DOOM 2D и MadSpace, но никого из них даже в ВК Плей не затащили, не то, чтоб они побежали портировать.
Если претендовать на какие-то новые игры, то, не знаю, мне кажется, должна быть какая-то намоленность. Например, Бейсик намоленный, и на Бейсике выезжают ClockworkPi PicoCalc и Maximite 2.
Проблема RISC-V в том, что он не намоленный. Чтобы его намаливать, надо через него пропустить реально много людей. Ну вот как через Бейсик пропустили. Это быстро не случится, как мне кажется. Мобилки чуть ли у не всех на ARM, но разработчики с этим ARM почти не работают в ассемблере, так что ARM так и остаётся не намоленным, в отличие от x86, который ковыряли активно, и литература по ассемблеру часто по x86. На x86 IBM PC была гармония: вот другой программист взял и написал Secret Agent, и показал, что можно компьютер заставить работать интересно, а вот мы тоже взяли написали на x86. Кажется, нам особенно не нужно уходить от x86. На x86 мешали патенты, но патенты действуют 20 лет, так что от текущего года можно отнять 20 лет, и любой процессор, который был 20 лет назад, сейчас в достоянии общественности. Для консоли процессор x86 образца 2005го года выше крыши.
Был такой компьютер, SEGA TeraDrive. x86 гибридизированный с SEGA. После него были более мощный Amstrad MegaPC, но в Меге СЕГА более отделена от ПК, чем в TeraDrive. В TeraDrive можно из DOS-части работать с графонием и музонием SEGA. А в обычном DOS с этим было тяжело. Многие, я думаю, в Turbo Pascal пытались игру написать, но скорость графики оставляла желать лучшего. На консолях были аппаратные тайлы и спрайты, а на ПК центральным процессором молотить биты и через шину ISA гонять в видеокарту EGA. На Амиге, кстати, с графонием было получше для 2D-игр. Везде было лучше для 2D, чем на ПК, и иронично, что VGA chunky mode 320x200x256 с быстрым процессором всё потом перевернул с ног на голову.
Так вот, а что если устроить сбычу мечт. Приделать-таки к x86 эпохи Turbo Pascal консольный графоний, и чтоб на Turbo Pascal можно было всё это программировать. Может ли Микрон делать x86-процессора? В СЕГЕ, кажется, 3МГц был центральный процессор, остальное тащили периферийные чипы. Микрон может делать консоли с 35МГц процессором. x86 с 35МГц процессором, разгруженным от перемолота графония, это может быть нормальная история.
Ещё можно намоленной архитектурой назвать MMIX. Она должна быть знакома читателям Искусства программирования. По нему курсы были в МехМате НГУ, правда, вроде бы, ещё на старом MIX, который может адресовать что-то вроде 16Кб. 4000 слов по 31 биту. Это и на код, и на данные. Ну вообще это примерно соответствует техническим характеристикам МИК Амур32, но не знаю, стоит ли сейчас обращаться к MIX. Четвёртый том, а, точнее, тома 4А, 4Б и планируемые следующие, пишутся только в новом MMIX, а для первых трёх томов MMIXmasters переписали все примеры с MIX на MMIX, и Dr. Martin Ruckert обобщил это в MMIX Supplement, который, по идее, должен войти в следующие издания всех первых трёх томов. MMIX устроен более привычно, в нём 64-битные слова и регистры, и байты из 8 бит, а не из шести как в MIX.
MMIX является непрактичным как реальный центральный процессор, так как у него 256 регистров общего назначения, а когда регистров много, для них обычно делают регистровое окно, а вот этого как раз в учебных целях на MMIX не сделано. Так что на MMIX относительно удобно писать на Ассемблере. В MMIXAL регистрам можно давать имена. Но для MMIX тяжело делать компилятор. Написанные на Ассемблере подпрограммы для MMIX как бы состоят из кучи разных соглашений о вызове, подогнанных так, чтобы всё держать в регистрах, а компиляторы языков высокого уровня всё в одно соглашение о вызове пытаются компилировать, и это значит регистры выгружать на стек и обратно постоянно, как на архитектурах с малым количеством регистров. Порт GCC на MMIX существует, и компилятор Паскаля в Перми писали, но вот с ним такой расклад. Лучше писать на ассемблере. И под MMIX много вручную написанного ассемблера. Пять томов разных алгоритмов. Только консольный графоний к MMIX ещё не пытались приделать.
Это была бы интересная провокация. Если бы не текущая ситуация, в районе Университета Мюниха могло бы вызвать ажиотаж, ну и в Стенфорде по старой памяти.
Так что, мне кажется, претендующая на эпичность консоль должна должна поддерживать x86 и MMIX. x86 можно в каком-то урезанном виде, без текстового режима. Пусть, допустим, в Turbo Pascal компилируются 16-битные exe, а консоль не может запустить IDE, но может запустить exe, собранные в Turbo Pascal.
должен находиться непосредственно в ведении министерства
И разработка в институте, в конструкторском бюро. Вообще, если так подумать, между разными странами общение может быть нужно, и надо ГОСТ принимать, налаживать мосты.
Какие-то сложные у вас схемы. Сам ГитХаб уже и так в нужной юрисдикции под крылом Майкрософта и настучит кому надо. Вот если бы дело происходило в начале 2000х, где куча вебмастеров понаделали форумов, и на них ходили и сидели в независимых учётках, и поверх этого взять и натянуть SSL, тогда да, тогда какая-то хитрость нужна. Потом пришло поколение людей, которые думают, что ВКонтакте это и есть Интернет. А когда уже и программисты как будто не подозревают, что можно взять Mercurial вместо Git, а даже если выбрать Git, не подозревают, что можно выбрать не GitHub, да чего тут особо мудрствовать.
Можно применить криптографию от нескольких систем и пожелать удачи тем, кто хотел бы собрать в одном месте правильных майоров от всех задействованных стран
В обоих случаях надо куда-то сходить, получить какую-то железку, подтвердить свою личность. Я когда к Госуслугам первый раз подключался, это было в отделении Ростелекома, сейчас как я понимаю, МФЦ. Так и в чём разница между походом в МФЦ и походом в УЦ?
Я вхожу в ГосУслуги только по смарт-карте. Ничего параноидального в этом не усматриваю, просто удобно. Смарт-карта красивая, единичный макет напечатали реверсной термопечатью, наклеили на белую смарт-карту от отечественного производителя ISBC (еСМАРТ токен ГОСТ).
Мне, наоборот, неудобно, когда всякие ГитХабы начинают чего-то мудрить, ещё какие-то устройства, в список которых, как-то так получилось, не вошли PC/SC. А почему нельзя в одном сделать. У многих на смарт-карте может быть AuthentiCode.
Desktop теряет популярность лет 20, а Delphi сильно погряз в десктопе и долго из него вылезал и до сих пор не вполне вылез. После Turbo Delphi 2006 не было долго бесплатных версий, в то время как другие раздавали. То Win32 с гигантским запозданием бесплатно, а Win64 платно. И сделали бесплатно когда уже совсем пора. Потом макос сделали, а мобильные платно. Но даже и макос долго был только 32-битным, где продвинутые возможности отрезали разработчикам.
Мы когда вакансии смотрим, сейчас ищут:
Фронт, для которого Delphi до сих пор предлагает зияющее ничто. Исполняющиеся на сервере формочки мало, кому подходят. Нужна автономность, идемпотентность, и нагрузку на сервера бы пониже, а если все формочки на сервере запущены и шевелятся, это странно. Так не делают.
Мобилки, для которых лишь совсем недавно появилась бесплатная версия Delphi.
Бэк, для которого бесплатной версии Delphi Linux нет, а ведь есть столько других бесплатных вариантов.
Embedded, где Delphi вообще ничего не предлагает, а субъективно эта ниша шире, чем desktop.
Desktop как-то вообще сжался. Раньше на софтпортал, на freesoft ходили, качали, делились. Сейчас кроме игр что кто качает. Когда последний раз заходили на freesoft скачать, вдруг Delphi программисты интересную программу написали.
Вот и получается, что Delphi такая, какая есть. Если работать, то может, ещё наладится.
А с шаблонами не понятно. Трудно их надёжно применять, не очень понятно, как подружить с ООП.
Допустим, у нас есть
type
Exception = class
public
property InnerException: Exception;
А ещё у нас есть
type
EInOutError = class(Exception)
public
property ErrorCode: Integer;
property Path: string;
Напишите шаблон, который рекурсивно проверяет цепочку Exception.InnerException, нет ли среди них EInOutError с ErrorCode = 200.
Ещё у нас есть
type
EAggregateException = class(Exception)
public
property Count: Integer read GetCount;
property InnerExceptions[Index: Integer]: Exception read GetInnerException; default;
Напишите шаблон, который найдёт EInOutError с ErrorCode = 200 среди InnerExceptions. Потоки завершаются непредсказуемо, может быть первый, может быть последний.
Немного усложним задачу.
Для более-менее обычных интерфейсов проверка принадлежности может быть сделана через System.SysUtils.Supports:
var Descendant: IDescendant;
if Supports(Ancestor, IDescendant, Descendant) then
begin
…
end {if};
Но если работать с обёртками объектов Андроиде, то у самой обёртки может быть тип, и этот тип не полон. Чтобы тестировать сам тип объекта Андроида, надо писать примерно так:
if TJNIResolver.IsInstanceOf(Ancestor, TJDescendant.GetClsID) then
begin
var Descendant: JDescendant := TJDescendant.Wrap(Ancestor);
…
end {if};
Каким синтаксисом нужно объяснять сопоставителю шаблонов эти нюансы?
Про кодировки трудно забыть, пока про них не забыли разработчики операционных систем. Например, в Linux можно создать файл с именем из невалидной последовательности символов UTF-8. Если пытаться себя убедить, что мы попали в чудесный мир Юникода, и на Юникоде пытаться сделать файловый менеджер с рекурсивным копированием и удалением директорий, он может не открыть, не смочь рекурсивно удалить или рекурсивно скопировать директорию с такими весёлыми файлами.
Ещё в UTF-8 есть разные способы кодировать одно и то же, и в Java этим активно пользуются, чтобы кодировать нулевой unicode codepoint двумя ненулевыми байтами при преобразовании в строку, заканчивающуюся нулевым байтом. Но это может быть не только нулевой codepoint. Не так давно PostgreSQL взламывали, кодируя восклицательный знак двумя байтами UTF-8.
Может быть, думаете, в WinAPI Юникод? А что, если создать файл из невалидной комбинации суррогатных пар.
Я составил обходной лист костылей для работы с кодировками Юникода:
Это как раз пример всестороннего загаживания пространства поиска. И модули из uses в общее пространство поиска вываливаются, без варианта оставить доступ по квалифицированным именам. И весь Self в пространство поиска вываливается. И with есть только такой, вываливающий всё в общую помойку.
В случае R по-хорошему так и надо оставить R, а в случае каких-то глубоких доступов надо обязывать давать имя, и доступ только через имя точка, а не общую помойку. В языке Ада declare renames вынудит задать имя.
Такие претензии, потому что я вижу как Си, C++, Java сплелись. Gtk на Си в обёртке Gtkmm для C++, и, наоборот, для C++ библиотек обёртки на Си. На полу-C++, полу-Java софт не редкость, LibreOffice таков, там UNO есть для автоматизации связывания C++ и Java-компонент. Противники Большого Паскаля почему-то на себя такой образ мысли не примеряют, чтоб какие-то свои пути. Пути, конечно, свои, но люди знают одно, другое, третье, и перетекает. Скажем, в C99 появились агрегаты.
struct xyz {
int a;
int b;
int c;
};
struct xyz klm = { .a = 99, .c = 100 };
В C++ их не было, а потом появились, и по какому-то совпадению по синтаксису оказались такие же. Это ведь не удивляет, правда? А ещё не удивляет, когда одно и то же называется одним и тем же термином. Вот, например, в PMtW был термин method resolution order, и тот же термин перетёк в Python, и чувствуется преемственность. Хотя в CLOS то же самое называется class linearization, и такой же термин в Dylan. Чувствуется, кто с кем больше общается.
Как само собой разумеющееся, в Большом Паскале, наоборот, нет такого общения. В языке Ада всю дорогу были controlled types, но в Delphi зачем-то изобрели термин managed records.
В Java была драматичная история с борьбой разных интерфейсов к Java-машине: NMI, JRI, RNI, и устаканилось на JNI. Оберонщики любят пенять, как джава всё украла, как аж целых две джава-машины выросли из оберон-машин: Esmertec Jbed и Excelsior JET. А, допустим, меня не нужно долго уговаривать, я уже патриот Паскаля, но не какого-то конкретного Паскаля. А где мне Oberon Native Interface, чтобы сделать программу из Ады, Delphi и Оберон-машины, как LibreOffice? Что-то не видать, а в чатах предлагается «соломоново решение» просто переписать всё на один язык.
Это пусть противники Большого Паскаля объединятся в большой кулак, и этим большим кулаком наподдают каждой ветке Большого Паскаля по отдельности, а в Большом Паскале, оказывается, какие-то свои пути. В Большом Паскале надо поодиночке выйти на арену против змеиного клубка из C, C++, Objective-C, Java, C#, и торжественно всосать.
У оберонщиков чуть ли не доблесть не знать Аду, адаистам кое-чем в Delphi тоже бы стоило глаза помозолить, но не торопятся мозолить, не разбегаются.
Сама Delphi, когда перестала быть Турбо Паскалём, многое позаимствовала из Модулы-3, и это поспособствовало тому, что это стал классный язык программирования. Жаль, с тех пор такие истории не повторялись. Как уже надоели эти свои пути, которыми прикрывается культивируемое невежество.
Нравится Ада
Да разное, бывает, нравится. Бывает, нравится возможность трансляции на разные платформы. Delphi Linux есть только на x86_64, а дешёвые роутеры на OpenWrt MIPS. Себе-то я на Озоне взял QOTOM за 30т.р. с процессором Celeron и шестью логически отдельными сетевыми портами, поставил OPNsense в Proxmox, и рядом в виртуалки самый разный софт могу ставить для хитрых туннелей. А что-то массовое, как у Roterich, делается на OpenWrt MIPS, и Delphi там нет, а Ада есть.
На Windows ARM, Эльбрус 2000 Линукс так и вообще почти никак не транслироваться, кроме как через Си и C++. Такая возможность есть у AdaMagic, но этот компилятор застрял в Ada 95. Так что супер переносимый код пишется на Ada 95, конечно, если не хочется напрямую вляпываться в слабую систему типов Си(++) и почти отсутствующую систему модулей. Delphi используется там, где есть сильные позиции, в UI на более-менее типичных платформах. На Windows ARM и Эльбрус 2000 Линуксе можно Delphi UI запускать в x86 эмуляции, а сложную логику писать на Аде 95. На Авроре, пока нет Delphi ARM Linux, хотя бы адские привязки к Qt надо брать, и всё на Аде программировать.
В языке Ада пошли другим путём. Character остался Character, String остался String, а к ним добавили сначала Wide_Character и Wide_String, а потом Wide_Wide_Character и Wide_Wide_String. И они между собой не конвертируются как в Delphi, так что случайно не ошибиться. А для файлов был Ada.Text_IO, а к нему добавились Ada.Wide_Text_IO и Ada.Wide_Wide_Text_IO, но это ещё конец истории. Они объявляют файловые типы с возможностью писать Юникод той или иной ширины, но имена файлов были String, а по букве стандарта это Latin-1. То есть, если программа запущена в Windows с кодировкой 866 и открывается файл, то по букве стандарта надо Latin-1 преобразовать в Юникод простым расширением нулевыми разрядами, и вызывать W-версию WinAPI. Хорошо или плохо, в известных реализациях я такое следование букве стандарта не видел, а видел 866 в A-версию и UTF-8. Но всё-таки в комитете стандартизации задумались, а что за фигня, и сделали в каждом из трёх пакетов вложенные пакеты Wide_File_Names и Wide_Wide_File_Names. Теперь у нас девять стандартных способов открыть текстовый файл, и самый труъ-юникодный Ada.Wide_Wide_Text_IO.Wide_Wide_File_Names.Open.
Ну что, как, похоже это на язык мечты? Всё как вы хотите сделали.
Да и немасштабных не хватает. Взять бы их разработчиков, и чтобы они поизучали Аду, и просто в Delphi взяло и появилось оттуда разное хорошее. А то не знают Аду и доходит как до жирафа. И особенно большое расстройство с немасштабных изменений, про которые объявление выглядело бы непафосно, вот и не снисходят, не делают, и ещё неизвестно, сколько лет пройдёт, пока не сделают.
У меня есть и другие хотелки, до которых, кажется, не соизволят снизойти годами из-за непафосности.
Забавно, что нужный мне синтаксис существует годами, так что первая строка компилируется (но, конечно, не сработает, нужен посложнее вариант). А в обычных вызовах такого синтаксиса нет. Можно в обычном вызове написать имя параметра в комментарий, но комментарий может быть неправильным, а поддержанное синтаксисом явное указание имени параметра будет проверено.
Однострочные if и for было бы здорово запретить, как в MISRA-C и SEI CERT C++ и уж тем более чтобы это не было в IDE шаблоном по умолчанию. Никлаус Вирт пожалел, что в Паскале не сделал правильно, и в Модуле сделал как надо. В языке Ада тоже сделали как надо.
declare
Some_Value : constant Integer := (if Condition then 2 else 3);
begin
Process (Some_Value);
end;
Местные переменные улучшают читаемость, а ещё лучше местные константы. Их нужно правильно объявлять с первого раза, и в языке Ада такие конструкции начали добавлять в русле отказа от изменчивости в стандарте от 2012 года.
А в Delphi местные переменные подвезли, а местные константы не подвезли, так что выглядит как что-то не очень важное.
Мне кажется, чтобы что-то такое выстреливало, нужно какой-то порог эпичности перейти.
Аутентичные консоли брали низкой ценой в регионах, где они становились лучшими за свою цену. В нашем регионе почти у всех есть мобилки. Хотя их не приходится назвать дешёвыми, но просто сейчас трудно найти игорька, у которого бы не было мобилки. А, значит, не очень понятно, как давить ценой.
Другие консоли берут высокой производительностью. Тоже мимо.
Третьи консоли берут ретро-совместимостью. Они дорогие, но на них что-то старое хорошо работает. Это ITX-Llama, x86 ретро-ПК с ISA DMA звуковой картой и встроенной эмуляцией Roland MT-32. Ещё как горячие пирожки разлетелась Apollo A6000, клон Амиги в механической клавиатуре.
EverCade подкупает тем, что игры у них лицензионные. Под наши консоли, кажется, нескоро начнут портировать как под EverCade. У нас вообще в России свои разработчики старых игр есть, можно вспомнить DOOM 2D и MadSpace, но никого из них даже в ВК Плей не затащили, не то, чтоб они побежали портировать.
Если претендовать на какие-то новые игры, то, не знаю, мне кажется, должна быть какая-то намоленность. Например, Бейсик намоленный, и на Бейсике выезжают ClockworkPi PicoCalc и Maximite 2.
Проблема RISC-V в том, что он не намоленный. Чтобы его намаливать, надо через него пропустить реально много людей. Ну вот как через Бейсик пропустили. Это быстро не случится, как мне кажется. Мобилки чуть ли у не всех на ARM, но разработчики с этим ARM почти не работают в ассемблере, так что ARM так и остаётся не намоленным, в отличие от x86, который ковыряли активно, и литература по ассемблеру часто по x86. На x86 IBM PC была гармония: вот другой программист взял и написал Secret Agent, и показал, что можно компьютер заставить работать интересно, а вот мы тоже взяли написали на x86. Кажется, нам особенно не нужно уходить от x86. На x86 мешали патенты, но патенты действуют 20 лет, так что от текущего года можно отнять 20 лет, и любой процессор, который был 20 лет назад, сейчас в достоянии общественности. Для консоли процессор x86 образца 2005го года выше крыши.
Был такой компьютер, SEGA TeraDrive. x86 гибридизированный с SEGA. После него были более мощный Amstrad MegaPC, но в Меге СЕГА более отделена от ПК, чем в TeraDrive. В TeraDrive можно из DOS-части работать с графонием и музонием SEGA. А в обычном DOS с этим было тяжело. Многие, я думаю, в Turbo Pascal пытались игру написать, но скорость графики оставляла желать лучшего. На консолях были аппаратные тайлы и спрайты, а на ПК центральным процессором молотить биты и через шину ISA гонять в видеокарту EGA. На Амиге, кстати, с графонием было получше для 2D-игр. Везде было лучше для 2D, чем на ПК, и иронично, что VGA chunky mode 320x200x256 с быстрым процессором всё потом перевернул с ног на голову.
Так вот, а что если устроить сбычу мечт. Приделать-таки к x86 эпохи Turbo Pascal консольный графоний, и чтоб на Turbo Pascal можно было всё это программировать. Может ли Микрон делать x86-процессора? В СЕГЕ, кажется, 3МГц был центральный процессор, остальное тащили периферийные чипы. Микрон может делать консоли с 35МГц процессором. x86 с 35МГц процессором, разгруженным от перемолота графония, это может быть нормальная история.
Ещё можно намоленной архитектурой назвать MMIX. Она должна быть знакома читателям Искусства программирования. По нему курсы были в МехМате НГУ, правда, вроде бы, ещё на старом MIX, который может адресовать что-то вроде 16Кб. 4000 слов по 31 биту. Это и на код, и на данные. Ну вообще это примерно соответствует техническим характеристикам МИК Амур32, но не знаю, стоит ли сейчас обращаться к MIX. Четвёртый том, а, точнее, тома 4А, 4Б и планируемые следующие, пишутся только в новом MMIX, а для первых трёх томов MMIXmasters переписали все примеры с MIX на MMIX, и Dr. Martin Ruckert обобщил это в MMIX Supplement, который, по идее, должен войти в следующие издания всех первых трёх томов. MMIX устроен более привычно, в нём 64-битные слова и регистры, и байты из 8 бит, а не из шести как в MIX.
MMIX является непрактичным как реальный центральный процессор, так как у него 256 регистров общего назначения, а когда регистров много, для них обычно делают регистровое окно, а вот этого как раз в учебных целях на MMIX не сделано. Так что на MMIX относительно удобно писать на Ассемблере. В MMIXAL регистрам можно давать имена. Но для MMIX тяжело делать компилятор. Написанные на Ассемблере подпрограммы для MMIX как бы состоят из кучи разных соглашений о вызове, подогнанных так, чтобы всё держать в регистрах, а компиляторы языков высокого уровня всё в одно соглашение о вызове пытаются компилировать, и это значит регистры выгружать на стек и обратно постоянно, как на архитектурах с малым количеством регистров. Порт GCC на MMIX существует, и компилятор Паскаля в Перми писали, но вот с ним такой расклад. Лучше писать на ассемблере. И под MMIX много вручную написанного ассемблера. Пять томов разных алгоритмов. Только консольный графоний к MMIX ещё не пытались приделать.
Это была бы интересная провокация. Если бы не текущая ситуация, в районе Университета Мюниха могло бы вызвать ажиотаж, ну и в Стенфорде по старой памяти.
Так что, мне кажется, претендующая на эпичность консоль должна должна поддерживать x86 и MMIX. x86 можно в каком-то урезанном виде, без текстового режима. Пусть, допустим, в Turbo Pascal компилируются 16-битные exe, а консоль не может запустить IDE, но может запустить exe, собранные в Turbo Pascal.
А если бы я захотел на чём-то современном поиграть в J2ME, на чём это лучше делать. Совместимость с N-Gage 2.0 приветствуется
Вот именно это я и думаю.
И разработка в институте, в конструкторском бюро. Вообще, если так подумать, между разными странами общение может быть нужно, и надо ГОСТ принимать, налаживать мосты.
Какие-то сложные у вас схемы. Сам ГитХаб уже и так в нужной юрисдикции под крылом Майкрософта и настучит кому надо. Вот если бы дело происходило в начале 2000х, где куча вебмастеров понаделали форумов, и на них ходили и сидели в независимых учётках, и поверх этого взять и натянуть SSL, тогда да, тогда какая-то хитрость нужна. Потом пришло поколение людей, которые думают, что ВКонтакте это и есть Интернет. А когда уже и программисты как будто не подозревают, что можно взять Mercurial вместо Git, а даже если выбрать Git, не подозревают, что можно выбрать не GitHub, да чего тут особо мудрствовать.
Можно применить криптографию от нескольких систем и пожелать удачи тем, кто хотел бы собрать в одном месте правильных майоров от всех задействованных стран
В обоих случаях надо куда-то сходить, получить какую-то железку, подтвердить свою личность. Я когда к Госуслугам первый раз подключался, это было в отделении Ростелекома, сейчас как я понимаю, МФЦ. Так и в чём разница между походом в МФЦ и походом в УЦ?
Я вхожу в ГосУслуги только по смарт-карте. Ничего параноидального в этом не усматриваю, просто удобно. Смарт-карта красивая, единичный макет напечатали реверсной термопечатью, наклеили на белую смарт-карту от отечественного производителя ISBC (еСМАРТ токен ГОСТ).
Мне, наоборот, неудобно, когда всякие ГитХабы начинают чего-то мудрить, ещё какие-то устройства, в список которых, как-то так получилось, не вошли PC/SC. А почему нельзя в одном сделать. У многих на смарт-карте может быть AuthentiCode.
Предлагаю ответ лучше:
Desktop теряет популярность лет 20, а Delphi сильно погряз в десктопе и долго из него вылезал и до сих пор не вполне вылез. После Turbo Delphi 2006 не было долго бесплатных версий, в то время как другие раздавали. То Win32 с гигантским запозданием бесплатно, а Win64 платно. И сделали бесплатно когда уже совсем пора. Потом макос сделали, а мобильные платно. Но даже и макос долго был только 32-битным, где продвинутые возможности отрезали разработчикам.
Мы когда вакансии смотрим, сейчас ищут:
Фронт, для которого Delphi до сих пор предлагает зияющее ничто. Исполняющиеся на сервере формочки мало, кому подходят. Нужна автономность, идемпотентность, и нагрузку на сервера бы пониже, а если все формочки на сервере запущены и шевелятся, это странно. Так не делают.
Мобилки, для которых лишь совсем недавно появилась бесплатная версия Delphi.
Бэк, для которого бесплатной версии Delphi Linux нет, а ведь есть столько других бесплатных вариантов.
Embedded, где Delphi вообще ничего не предлагает, а субъективно эта ниша шире, чем desktop.
Desktop как-то вообще сжался. Раньше на софтпортал, на freesoft ходили, качали, делились. Сейчас кроме игр что кто качает. Когда последний раз заходили на freesoft скачать, вдруг Delphi программисты интересную программу написали.
Вот и получается, что Delphi такая, какая есть. Если работать, то может, ещё наладится.
Про выдающуюся понятность языка Си: https://c-faq.com/decl/spiral.anderson.html
В языке Ада есть case.
А с шаблонами не понятно. Трудно их надёжно применять, не очень понятно, как подружить с ООП.
Допустим, у нас есть
А ещё у нас есть
Напишите шаблон, который рекурсивно проверяет цепочку Exception.InnerException, нет ли среди них EInOutError с ErrorCode = 200.
Ещё у нас есть
Напишите шаблон, который найдёт EInOutError с ErrorCode = 200 среди InnerExceptions. Потоки завершаются непредсказуемо, может быть первый, может быть последний.
Немного усложним задачу.
Для более-менее обычных интерфейсов проверка принадлежности может быть сделана через System.SysUtils.Supports:
Но если работать с обёртками объектов Андроиде, то у самой обёртки может быть тип, и этот тип не полон. Чтобы тестировать сам тип объекта Андроида, надо писать примерно так:
Каким синтаксисом нужно объяснять сопоставителю шаблонов эти нюансы?
Не зарастает тропа от детей, желающих купить и продать сим-карту. Подержать в руках первые в жизни заработанные деньги
Про кодировки трудно забыть, пока про них не забыли разработчики операционных систем. Например, в Linux можно создать файл с именем из невалидной последовательности символов UTF-8. Если пытаться себя убедить, что мы попали в чудесный мир Юникода, и на Юникоде пытаться сделать файловый менеджер с рекурсивным копированием и удалением директорий, он может не открыть, не смочь рекурсивно удалить или рекурсивно скопировать директорию с такими весёлыми файлами.
Ещё в UTF-8 есть разные способы кодировать одно и то же, и в Java этим активно пользуются, чтобы кодировать нулевой unicode codepoint двумя ненулевыми байтами при преобразовании в строку, заканчивающуюся нулевым байтом. Но это может быть не только нулевой codepoint. Не так давно PostgreSQL взламывали, кодируя восклицательный знак двумя байтами UTF-8.
Может быть, думаете, в WinAPI Юникод? А что, если создать файл из невалидной комбинации суррогатных пар.
Я составил обходной лист костылей для работы с кодировками Юникода:
Консольные программы запускаются с 866 по умолчанию. Для переключения можно вызывать SetFileApisToANSI.
Это как раз пример всестороннего загаживания пространства поиска. И модули из uses в общее пространство поиска вываливаются, без варианта оставить доступ по квалифицированным именам. И весь Self в пространство поиска вываливается. И with есть только такой, вываливающий всё в общую помойку.
В случае R по-хорошему так и надо оставить R, а в случае каких-то глубоких доступов надо обязывать давать имя, и доступ только через имя точка, а не общую помойку. В языке Ада declare renames вынудит задать имя.
В Модула-3 синтаксис with изменён от Модулы-2, и имя стало возможным и обязательным к указанию.
Такие претензии, потому что я вижу как Си, C++, Java сплелись. Gtk на Си в обёртке Gtkmm для C++, и, наоборот, для C++ библиотек обёртки на Си. На полу-C++, полу-Java софт не редкость, LibreOffice таков, там UNO есть для автоматизации связывания C++ и Java-компонент. Противники Большого Паскаля почему-то на себя такой образ мысли не примеряют, чтоб какие-то свои пути. Пути, конечно, свои, но люди знают одно, другое, третье, и перетекает. Скажем, в C99 появились агрегаты.
В C++ их не было, а потом появились, и по какому-то совпадению по синтаксису оказались такие же. Это ведь не удивляет, правда? А ещё не удивляет, когда одно и то же называется одним и тем же термином. Вот, например, в PMtW был термин method resolution order, и тот же термин перетёк в Python, и чувствуется преемственность. Хотя в CLOS то же самое называется class linearization, и такой же термин в Dylan. Чувствуется, кто с кем больше общается.
Как само собой разумеющееся, в Большом Паскале, наоборот, нет такого общения. В языке Ада всю дорогу были controlled types, но в Delphi зачем-то изобрели термин managed records.
В Java была драматичная история с борьбой разных интерфейсов к Java-машине: NMI, JRI, RNI, и устаканилось на JNI. Оберонщики любят пенять, как джава всё украла, как аж целых две джава-машины выросли из оберон-машин: Esmertec Jbed и Excelsior JET. А, допустим, меня не нужно долго уговаривать, я уже патриот Паскаля, но не какого-то конкретного Паскаля. А где мне Oberon Native Interface, чтобы сделать программу из Ады, Delphi и Оберон-машины, как LibreOffice? Что-то не видать, а в чатах предлагается «соломоново решение» просто переписать всё на один язык.
Это пусть противники Большого Паскаля объединятся в большой кулак, и этим большим кулаком наподдают каждой ветке Большого Паскаля по отдельности, а в Большом Паскале, оказывается, какие-то свои пути. В Большом Паскале надо поодиночке выйти на арену против змеиного клубка из C, C++, Objective-C, Java, C#, и торжественно всосать.
У оберонщиков чуть ли не доблесть не знать Аду, адаистам кое-чем в Delphi тоже бы стоило глаза помозолить, но не торопятся мозолить, не разбегаются.
Сама Delphi, когда перестала быть Турбо Паскалём, многое позаимствовала из Модулы-3, и это поспособствовало тому, что это стал классный язык программирования. Жаль, с тех пор такие истории не повторялись. Как уже надоели эти свои пути, которыми прикрывается культивируемое невежество.
Да разное, бывает, нравится. Бывает, нравится возможность трансляции на разные платформы. Delphi Linux есть только на x86_64, а дешёвые роутеры на OpenWrt MIPS. Себе-то я на Озоне взял QOTOM за 30т.р. с процессором Celeron и шестью логически отдельными сетевыми портами, поставил OPNsense в Proxmox, и рядом в виртуалки самый разный софт могу ставить для хитрых туннелей. А что-то массовое, как у Roterich, делается на OpenWrt MIPS, и Delphi там нет, а Ада есть.
На Windows ARM, Эльбрус 2000 Линукс так и вообще почти никак не транслироваться, кроме как через Си и C++. Такая возможность есть у AdaMagic, но этот компилятор застрял в Ada 95. Так что супер переносимый код пишется на Ada 95, конечно, если не хочется напрямую вляпываться в слабую систему типов Си(++) и почти отсутствующую систему модулей. Delphi используется там, где есть сильные позиции, в UI на более-менее типичных платформах. На Windows ARM и Эльбрус 2000 Линуксе можно Delphi UI запускать в x86 эмуляции, а сложную логику писать на Аде 95. На Авроре, пока нет Delphi ARM Linux, хотя бы адские привязки к Qt надо брать, и всё на Аде программировать.
В языке Ада пошли другим путём. Character остался Character, String остался String, а к ним добавили сначала Wide_Character и Wide_String, а потом Wide_Wide_Character и Wide_Wide_String. И они между собой не конвертируются как в Delphi, так что случайно не ошибиться. А для файлов был Ada.Text_IO, а к нему добавились Ada.Wide_Text_IO и Ada.Wide_Wide_Text_IO, но это ещё конец истории. Они объявляют файловые типы с возможностью писать Юникод той или иной ширины, но имена файлов были String, а по букве стандарта это Latin-1. То есть, если программа запущена в Windows с кодировкой 866 и открывается файл, то по букве стандарта надо Latin-1 преобразовать в Юникод простым расширением нулевыми разрядами, и вызывать W-версию WinAPI. Хорошо или плохо, в известных реализациях я такое следование букве стандарта не видел, а видел 866 в A-версию и UTF-8. Но всё-таки в комитете стандартизации задумались, а что за фигня, и сделали в каждом из трёх пакетов вложенные пакеты Wide_File_Names и Wide_Wide_File_Names. Теперь у нас девять стандартных способов открыть текстовый файл, и самый труъ-юникодный Ada.Wide_Wide_Text_IO.Wide_Wide_File_Names.Open.
Ну что, как, похоже это на язык мечты? Всё как вы хотите сделали.
Да и немасштабных не хватает. Взять бы их разработчиков, и чтобы они поизучали Аду, и просто в Delphi взяло и появилось оттуда разное хорошее. А то не знают Аду и доходит как до жирафа. И особенно большое расстройство с немасштабных изменений, про которые объявление выглядело бы непафосно, вот и не снисходят, не делают, и ещё неизвестно, сколько лет пройдёт, пока не сделают.
У меня есть и другие хотелки, до которых, кажется, не соизволят снизойти годами из-за непафосности.
Забавно, что нужный мне синтаксис существует годами, так что первая строка компилируется (но, конечно, не сработает, нужен посложнее вариант). А в обычных вызовах такого синтаксиса нет. Можно в обычном вызове написать имя параметра в комментарий, но комментарий может быть неправильным, а поддержанное синтаксисом явное указание имени параметра будет проверено.
Однострочные if и for было бы здорово запретить, как в MISRA-C и SEI CERT C++ и уж тем более чтобы это не было в IDE шаблоном по умолчанию. Никлаус Вирт пожалел, что в Паскале не сделал правильно, и в Модуле сделал как надо. В языке Ада тоже сделали как надо.
UPD. Со знаком = компилируется
Где это критически нужно:
Местные переменные улучшают читаемость, а ещё лучше местные константы. Их нужно правильно объявлять с первого раза, и в языке Ада такие конструкции начали добавлять в русле отказа от изменчивости в стандарте от 2012 года.
А в Delphi местные переменные подвезли, а местные константы не подвезли, так что выглядит как что-то не очень важное.
К истории вопроса, идущей корнями в Алгол 60
http://www.ada-auth.org/standards/12rat/html/Rat12-3-2.html