Ответы для темы «Почему Go это плохо....»

Там паскалист из КНДР косплэил Брюса Ли, он всех победил но в конце одинэсник пырнул его

Ну ладно, паскалист потому, что сидел на трубах, понемаю. А одинэсник-то почему?

А трубах что? Давление. А давление в чем? В паскалях

А чо тогда про 7.7 трындишь?

Довод простой. Под новое оборудование не будет драйверов для старых ОС.

А еще довод - новые API в операционной системе. И то, что разработчикам нахер не вперлось поддерживать что-то там старое, для которого надо городить сраные костыли.

Я лично когда речь идет о клиентском софте, в 2023м году сразу готов говорить - минимальная поддерживаемая версия винды - Windows 10. Ретрограды, контрамоты и говноеды пусть идут к херам, ковыряются в грязи, и жрут говно. Хера им с три а не софт. Пусть ставят себе хоть Windows 3.11 и играют там в пасьянс «косынка».

Это я еще не говорю про Security Updates итд, которые под ОС с вышедшим сроком поддержки и вообще годности(типа семерки), не делают.

ТС буквально: https://pbs.twimg.com/media/EcB2x4bWkAcARln.jpg

Я лично когда речь идет о клиентском софте, в 2023м году сразу готов говорить - минимальная поддерживаемая версия винды - Windows 10.

Так и запишем — не осилил.

Ретрограды, контрамоты и говноеды

…в переводе с твоего на русский — это люди, которые не хотят выбрать старую работающую технику, видимо.

ковыряются в грязи, и жрут говно

– то, чем всем придётся заниматься на убитой отходами планете. К сожалению, всем, а не только тем, кто не умеет в совместимость с умеренно старыми ОС, это действительно проблема.

Я лично когда речь идет о клиентском софте, в 2023м году сразу готов говорить - минимальная поддерживаемая версия винды - Windows 10

Напомни, почему ты до сих пор не свалил на винфак

Из-за того, что винфак всё?

Более хайповой была бы тема про раст. Потому как язык ряльно ужасен. В Go PascalCase мне только не нравится и отсутствие вменяемого перехвата ошибок

Потому как язык ряльно ужасен.

Вот бы ты еще разбирался в вопросе, чтобы делать столь категоричные утверждения 😁.

Так как в Лисп можно в run-time использовать исходные тексты модулей, то наверное можно для вашего клиента разработать run-time генератор Лисп модулей согласно некоего исходного алгоритма или запроса.

То бишь некий свой ЯП.

Шутка

Совместимый с синтаксисом ЯП фирмы 1С.

да нет, не шутка. лет 11 назад мне надоела 7.7 и 8.2 – я почувствовал как тупею. и я начал изобретать свой её аналог (вдохновившись 2Cgpl, только там простой интерпретатор, а я писал компилятор/транспилятор). оказалось не сильно сложно.

написал парсер 7.7 на ANTLR и транслятор его распарсенного AST в другое всякое.

в ANTLR 3.4 есть метод ((Tree)parser.tree).toStringTree(), который прямо так берёт и выводит AST сгенерированного parser в виде S-выражений.

как-то копипастил её на лоре в несколько постов, там несложно. парсер сам простой, основная сложность – в ANTLR грамматике. опять же, если делать правильные семантические предикаты – то тоже нетривиально, если забить и делать динамически – но гораздо проще.

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

примерно за пару месяцев, не сильно тратя время по паре часов вечерами – допилил прототип. основное время заняло чтение книжек по ANTLR и настройка плагина ANTLR в Eclipse.

потом немного повозился с правильным pretty printing-ом, но забил – готовая функция в Emacs и так неплохо справляется с форматированием лисп-кода.

в общем, получился такой простой и примитивный транслятор грамматики 7.7 и любой программы на ней в S-выражения.

потом с небольшим количеством макросов на лиспе, которые непосредственно исполняли либо переводили на другой язык (например, лисп) – получился готовый интерпретатор/компилятор 7.7 в лисп.

ещё возился с перенацеливанием с целевого лиспа в целевой оберон, затем аду.

потом в мумпсы.

в общем, поразвлекался пару месяцев вечерами.

PDF делать проще, со встроенными TrueType шрифтами. в .PS нужно Type1 и возиться с кодировками.

Технология разработки ЯП с использованием грамматик не пригодна для создания ЯП с хорошим синтаксисом.

что такое «хороший синтаксис» и почему он хорош?

это какая именно технология и почему? что на ANTLR, что на CoCo/R пишется несложно, и синтаксис любой можно довольно просто сделать.

есть более правильная идеологически – K framework. там примерно как в ANTLR v3 gUnit, нужно начинать сразу с тестов и определять семантические предикаты, продвигаться сразу в семантику.

там тоже не очень сложно выглядит.

Линковщики застыли в 60-х и не понимают, что такое динамические переменные и много много более.

вот да, по Вашей ссылке, Владимир – на UCSD p-code system нашёл рассадник цитатник высказываний и книг Эдсгера Дейкстры и Никлауса Вирта.

сейчас вот перечитывал «Долой жирные программы». где он как раз рассказывал про design decisions повлиявшие на то как он Oberon-2 делал.

сделали расширение типов – правильное, с учётом наследования, перехода через границы модулей.

в какой-то другой книжке про оберон (то ли алгоритмы+данные=программы, то ли про конструирование компиляторов) – про метод пошагового уточнения /stepwise refinement и разницу между независимой и раздельной компиляцией модулей. (или это в книжке про модулу?)

независимая компиляция – взяли все модули, собрали в объектники. произошло стирание типов и много лишней работы из-за того что метаинформация о типах модуля на этом этапе отсутствует.

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

при этом модули не приходится перекомпилировать заново. на них вообще могут исходники отстутствовать.

в общем, сравнивая между собой операционную систему, которая запускает процессы которые падают в корку (с дампом образа процесса) – и операционную среду, которая гарантирует, что модуль в отличие от процесса запустится максимум один раз, и что в отличие от объектника или .dll метаинформация о экспортированных типах модуля корректно работает через границы модулей, и что нужно какое-то дальнейшее упрощение этих принципов и концепций – но сохраняя существенное, с возможностями прозрачного расширения –

видно все эти ценности и проектные решения которые были сознательно выбраны в проекте оберон.

в общем, долой жирные программы!! довольно познавательным чтивом оказалось, с эдаким design rationale

даже Plan 9 и Inferno выглядят какой-то вторичной и опоздавшей попыткой исправиться. сравнивая оберон и limbo, второй как-то более на виртуальную машину завязан (она хоть и регистровая Dis, но всё таки, с модульностью и корректной статической типизацией там другой подход).

в общем, что оберон, что активный оберон, что инферно выглядит какой-то более продуманной расширяемой операционной средой.

да даже тот же p-code в паскалях, m-сode в модулах, o-code в BCPL.

чем это вот жёлто-красное поделие, ога. :))

что такое «хороший синтаксис» и почему он хорош?

Например в Си if ( VpInt01 = VpInt02 ) является синтаксически правильным, а наверняка должно быть if ( VpInt01 == VpInt02 ).
Оператор запятая тоже может способствовать ошибкам в исходном коде.
Например:

 VpInt01 = VpInt03 > 1,
           15,
           16;

Всякие красивые синтаксические «фантики», ...

в общем, что оберон, что активный оберон,

Здесь важна не реализация Оберон, а новый технологический подход к разработке проектов.

Полная чушь, а компилятор видит в этом что-то полезное.

компилятор просто буквально переводит что написано и не додумывает отсебятины.

синтаксис в этом смысле должен устранять неоднозначности – например, if {LogicExp} then {op} else {op} endif одназначно подразумевает, что выражение логическое вычисляющееся в true/false, что op – оператор а не выражение, то есть, для которого важны побочные эффекты а не возвращаемое значение и т.п.

в этом смысле попытка налепить всё в одно-единственное выражение – пример того, как делать можно, но не нужно: нарушается соответствие синтаксиса и семантики, плотно упаковывая в одно выражение.

с другой стороны, если бы например это был функциональный язык. то op может быть например лямбдой, которую можно погрузить в другую лямбду либо конструкцию наподобие let over lamda – то есть, замыкание. то есть, упрощая композицию за счёт корректных типов выражений.

Оператор запятая тоже может способствовать ошибкам в исходном коде.

Это ещё что, вот у А. В. Столярова которого некоторые огульно хаят не читая – есть лисп InteLib, полученный трансляцией в С++ выражения.

в описании есть некая «операция пробел», конструирующая лисп-выражения в некоторой алгебре.

типа как в языке Io пробелом можно показывать вызов метода прототипного ООП и цепочечный вызов методов, только здесь раскрутка S-выражений в С++-выражения некоторых классов получается частично во время компиляции шаблонами, частично – во время выполнения.

лисп был раскручен в более-менее полноценный диалект схемы.

был у него студент, который написал аналогичную раскрутку на D, а не на С++.

D в этом смысле более перспективный язык – из-за CTFE и информации о типах времени выполнения, typeinfo в модулях.

было это (InteLib) примерно в 2006, диалект на D (Scheme4d.tar.gz) – примерно 2007..2008.

в это время D был диалекта D1, со многими ограничениями. например, 3D стрелялку Deadlock на D писал h3r2tic сайт наподобие quake – там на CTFE были шейдеры и множество фич завязаны. D1 в то время был не зрелым – в линкере digital mars OPTLINK были проблемы, некоторые фичи были в стандартной библиотеке phobos не доделаны. в той стрелялке они сделали свой форк D1, рантайма phobos и попутно написали средство сборки xfbuild.

ещё он делал Nuklear-подобный GUI: Hybrid, стрелялку Deadlock, xfbuild и CTFE raytracer на D ctrace.

большинство наворотов в Hybrid, Deadlock, ctrace сделаны во время компиляции (CTFE).

сейчас он похоже, растом увлёкся.

сейчас этот код Scheme4d бы стоило на D2 переписать.

например, когда в разработку D подключился Александреску – там появился std.algorithm как более полноценный аналог boost-а и Loki (про локи кажется тот же Александреску книжку написал, которой можно детей пугать – пример шаблонов головного мозга показывающий скорее то, как делать не надо. впрочем, в книге Александреску про D2 с описанием std.algorithm стало наконец понятно, к чему это всё было – из-за более полноценной поддержки typeinfo и CTFE в D, библиотеки наподобие STL std.algorithm поддерживает «лямбды времени компиляции» которые транслируются как string mixin, template mixin в D.

например, на D2 есть библиотека с некрасивым названием pegged позволяющая написать рекурсивный нисходящий парсер на CTFE выражениях времени компиляции.

из примеров в этой библиотеке есть, например, Oberon-2 или extended_pascal.

PEG выражения во время компиляции (CTFE) параметризуются нужной грамматикой и раскрываются в итоговые выражения через string mixin/template mixin – в полноценный код на языке D.

то есть, если бы например в подобном стиле переписать на D2 вот тот код Scheme4d.tar.gz студента Столярова – то возможно, получилось бы вообще обойтись только выражениями времени компиляции, с ещё меньшими накладными расходами на рантайм-поддержку объектных выражений полученных в алгебре программ с «операцией пробел» трансляцией из S-выражений исходного лиспа в целевой D2 (а не С++)

в общем, сделать такой лисп с минимальным рантаймом – потому что в основном вся раскрутка происходит во время компиляции, CTFE макросами.

в InteLib на С++ А.В. Столярова с «операцией пробел» в этом смысле не совсем правильный СTFE, ибо С++.

На D2 этот подход был бы реализован более прозрачно и правильно.

Здесь важна не реализация Оберон, а новый технологический подход к разработке проектов.

подход не такой уж и новый – всё новое это хорошо забытое старое.

«лишняя функция – это бОльшая ненадёжность и узязвимость», поэтому фичи и концепции нужно оценивать не столько поо количеству – сколько по качеству.

просто концепции – существенные, essential в основании должны быть правильные. допускающие адекватное расширение.

Э. Дейкстра давным-давно писал про «скромного программиста» humble programmer, дисциплину программирования, упрощение до минимализма, а не примитивизма используемых концепций.

минимализм – это про то, как выразить бОльший смысл малыми средствами.

примитивизм – это когда нет никаких бОльших смыслов кроме примитивно накаляканых.

в этом смысле, нужно как писал А. Белый в книге «Символизм как миропонимание» – не столько пассивное мировозрение, мировосприятие, любомудрие и прочее потакание собственной важности.

сколько активное преобразование реальности, этакий перфоманс – миропонимание. того как применить все эти символы и концепции, подходы, принципы и парадигмы.

Н. Вирт уточнил в stepwise refinement методе пошагового уточнения – как правильно нужно набрасывать абстракции.

в «долой жирные программы!» – выяснилось, что важно не просто количество фич, но их качество: структура, модульность, адекватное расширение типов.

в книге про устройство компонентной модели SOM для OS/2, например, тоже похожий подход: берём сначала принципы (ABI не должно ломаться при изменении класса в предка и потомка, двигая его по иерархии наследования) – то есть, реализация этих принципов должна сохранять некоторые инварианты. потом реализуем эти принципы и получается некоторый shim, trampoline для реализации SOM API, и компилятор VisualAge C++ который С++ классы в такие вот SOM классы на plain C ABI прозрачно транслирует.

для поддержки адекватного расширения типов – вводят метаинформацию, typeinfo о модулях и другой, более объектно-ориентированный линкер, лоадер.

в Plan 9 компилятор kencc тоже кстати переделывают 6c/6l, 8c/8l – более другой линкер/лоадер.

и внезапно, оказывается что можно делать разработку инкрементально, итеративно, модульно.

и не ждать пока по полчаса C++ шаблоны на BOOST или STL откомпилируются :))

в общем, и Никлаус Вирт в оберонах и Керниган, Пайк и Ритчи в Plan9 и Inferno, и Волтер Брайт, Александреску, h3r2tic,PhilippeSigaud показали – чего можно достичь адекватно структурированной модульностью.

даже на С можно писать аккуратно и модульно. только большинство так не делает :)

С++ в этом смысле наоборот, провоцирует писать монолитные жирные программы.

и пока продаются фичи по количеству, а не по качеству (никто же не покупает «правильную архитектуру» как более ценную фичу) – этот театр абсурда и будет продолжаться.

в оберонах, инферно, да даже том же p-code и паскалине – нужно немножко отстраниться назад и посмотреть не замыленным взглядом.

какие фичи наиболее важные, а какие концептуально не правильны.

как должно развиваться ядро системы, и как её модули.

по каким принципам должна строиться и развиваться система – чтобы не требовать бесконечной перекомпиляции.

в общем, интересные соображения появляются.

может даже, бОльшая часть такой системы должна быть сделана например на модульном, правильно структурированном лиспе.

или ещё каком языке – допускающим адекватное конструирование высокоуровневых конструкций из адекватно подобранных низкоуровневых.

например, была такая реализация оберона на языке Ocaml: Oxford_Oberon-2_compiler и соответствующий курс как и соответствующий ему курс по конструированию_компиляторов

репозиторий на гитхабе: Spivoxity/obc-3

ещё у него есть picopascal на котором написан picoProlog

операция пробел

вот тут подробнее написано:

А. В. Столяров. Парадигмы программирования и алгебраический подход к построению универсальных языков программирования.

в публикациях этого весьма интересного автора

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

шок. скандалы, интриги. расследования.