Как грамотно и качественно создать свой ЯП?

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

Golang же. Чем не новый процедурный язык, убийца сишечки.

убийца сишечки.

Не, даже близко не встанет. Киллер фич нет, с некоторыми вещам перемудрили.

убийца сишечки

тридцать лет наблюдаю, как школота тщится «убить» сишечку. только сишечка и поныне здравствует, а вот всякие «убийцы сишечки» давно канули в лету.

я так понимаю, что все попытки создать замену сишечке вызывны острым баттхёртом из-за неспособности её осилить.

из-за неспособности её осилить

Не правильно понимаешь. Там нечего «осиливать».

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

сишечка успешно работает уже много лет и никаких проблем с ней нет.

Точно. А вот с людишками проблемы - не умеют писать на Си без Heartbleed.

ну так это проблемы людишек, а не языка. песочницы для неосиляторов - это для обучения школотронов, а не для работы.

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

сишечка успешно работает уже много лет и никаких проблем с ней нет.

Точно. А вот с людишками проблемы - не умеют писать на Си без Heartbleed.

ну так это проблемы людишек

Ну вот люди их стараются решить - делают новые языки. Рано или поздно эту проблему решат.

песочницы для неосиляторов - это для обучения школотронов, а не для работы.

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

я-то уж давно не школотрон. школотроном я была лет двадцать с лишним назад. и то я тогда писала на ассемблере и С и не плакала, что «памятью неудобно управлять». для десятилетнего школотрона это было по силам. а сейчас взрослые дяди с усами плачутся, что у них какие-то проблемы с программированием. хипстеры сраные. я этого не понимаю и не пойму никогда. с сишечкой всё нормально, если руки не из жопы и голова на плечах имеется.

я считаю так: если программирование не выходит, вероятно, подметание дворов - твоё призвание. и не надо для этого изобретать новые языки. надо просто признать, что есть рукожопы, которые должны подметать дворы. это тоже полезное дело.

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

я-то уж давно не школотрон

Об этом я и говорил.

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

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

Хорошо. А вы в одну осилите все потребности этой планеты в плане автоматизации? Будете заниматься написанием конфигураций для оптовой торговли семечками и орехами? Или ПО для регистратуры в больнице? Сделаете сайт для фанатов Стаса Михайлова или Битвы экстрасенсов? На Си, я как полагаю всё будете делать?

Ты получаешь коллбеки и умеешь манипулировать HTML DOM из Java на Chromium?

До этого еще не дошел, точнее пока в этом нет сильной потребности. Но по сути, в хромиуме, весь DOM API мапится на крестовые классы. Вот сейчас даже ради любопытства глянул:

native public Array<Element> elementsFromPoint(int x, int y);

HeapVector<Member<Element>> Document::elementsFromPoint(int x, int y) const {
  if (layoutViewItem().isNull())
    return HeapVector<Member<Element>>();
  return TreeScope::elementsFromPoint(x, y);
}

На JS ничего нет, только IDL и всё. Все IDL распарсены и преобразованы в Java интерфейсы. Нужно лишь разобраться, где всё это биндится на крестовые классы и подменить на свою реализацию.

Поэтому мне непонятно, почему «HTML без JS всё равно не живет», когда в хромиуме попросту нет этого JS, всё реализовано в крестовых классах.

А смысл всего упражнения - писать десктопные приложения на Java + HTML? Чем Electron - JS + JVM будет лучше, чем просто Electron?

В JVM больше полезных вещей для прикладника. Плюс наличие библиотек сделанных на джаве, а не на жс.

Но сейчас мне нужнее разработка веб-сайтов, поэтому текущая стратегия IDL->Java->ES6+Chromium и JVM на бекенде связанная по websocket или ajax с фронтендом.

Хотя смотрю Promise на V8 завязано, возможно это не так всё просто окажется )

Поэтому мне непонятно, почему «HTML без JS всё равно не живет»

Потому что много интересного (или даже почти всё интересное) реализуется на JS. Предлагая делать всё через Java, ты 1) отсекаешь всю армию HTML/JS кодеров 2) делаешь разработку как минимум нетехнологичной (если не нашел еще способа помещать Java-код в страницу).

А смысл всего упражнения - писать десктопные приложения на Java + HTML? Чем Electron - JS + JVM будет лучше, чем просто Electron?

В JVM больше полезных вещей для прикладника. Плюс наличие библиотек сделанных на джаве, а не на жс.

Ну то есть Electron используется в роли очередного GUI-тулкита для Java? Предыдущие 3 или 4 раза (AWT, Swing, JavaFX, SWT) на десктопе это не взлетело.

Хотя всякие там Songbird тоже когда-то не взлетели, а сейчас их души вернулись в виде Electron-приложений.

Хотя всякие там Songbird тоже когда-то не взлетели, а сейчас их души вернулись в виде Electron-приложений.

Не знаю чё такое Songbird. Но под винду было(есть) HTA.(хотя понятно почему не взлетело, потому что проприетарщина некроссплатформенная да ещё и движок ИЕ).

Не знаю чё такое Songbird. Но под винду было(есть) HTA

Не знаю чё такое HTA.

HTML Application
https://en.wikipedia.org/wiki/HTML_Application
Electron/nodejs опередивший своё время.

отсекаешь всю армию HTML/JS кодеров
(если не нашел еще способа помещать Java-код в страницу).

Они на React/Angular сейчас пишут, а потому джава проект будет отличаться лишь статической типизацией от жс проекта. А с тайпскриптом будет чуть ли не один в один. В этом плане даже ржавый будет почти не отличим: https://github.com/DenisKolodin/yew/blob/master/examples/todomvc/src/main.rs#...

Ну то есть Electron используется в роли очередного GUI-тулкита для Java? Предыдущие 3 или 4 раза (AWT, Swing, JavaFX, SWT) на десктопе это не взлетело.

Когда GUI на HTML и DOM, то любой может начать писать свой UI без изучения тон документации по очередном фреймворку.

Рынок ПО, на котором по факту 2.5 реально успешных программиста (мв, пол грэм и кто там еще), это скорее насмешка над технологией, чем вин.

2.5 плюсь несколько десятков миллионов админов. shell — это внезапно тоже repl.

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

(согласен (! ((да зравствует) lisp)))

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

«Только лишь»? React - это JSX, который расширение JS, а не Java; Angular тоже на основе JS. Не говоря о том, что там замешаны специальные компиляторы.

В этом плане даже ржавый будет почти не отличим: https://github.com/DenisKolodin/yew/blob/master/examples/todomvc/src/main.rs#...

Ну, если необходимость писать на другом языке - это «почти неотличим», то конечно.

Когда GUI на HTML и DOM, то любой может начать писать свой UI без изучения тон документации по очередном фреймворку.

Чтобы пользоваться Electron как Java GUI toolkit, нужно знать и HTML/CSS, и Java. Много ли таких спецов.

average_ball

Ты с помощью этого класса тестикулы измерять хочешь бедным студентам?

1. Объём кода современного ЯП - от 10 Мб и выше, время от начала разработки до выхода версии 1.0 - от 3 лет. Здраво оцени свои силы.

От 10 Мб в архиве / с докой / с тестами / или как?

Sbcl который некоторый монстрик среди лиспов 37 мб текстом. Ecl который построен вокруг сс - 22. Corman - 14. CLPython который реализация питона на лиспе с полным синтаксисом но урезаными батарейками - 1,3. Последний для сравнения с языками полного цикла.

отсекаешь всю армию HTML/JS кодеров (если не нашел еще способа помещать Java-код в страницу).

Они на React/Angular сейчас пишут, а потому джава проект будет отличаться лишь статической типизацией от жс проекта. А с тайпскриптом будет чуть ли не один в один. В этом плане даже ржавый будет почти не отличим: https://github.com/DenisKolodin/yew/blob/master/examples/todomvc/src/main.rs#...

fn view(model: &Model) -> Html<Msg> {
    html! {
<div class="todomvc-wrapper",>

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

1. Объём кода современного ЯП - от 10 Мб и выше, время от начала разработки до выхода версии 1.0 - от 3 лет. Здраво оцени свои силы.

От 10 Мб в архиве / с докой / с тестами / или как?

Он имел в виду объем срачей на ЛОР по ходу работы над языком.

Много ли таких спецов.

Хочу выяснить, готовлю парсер гитхаба по юзерам с 2009 по 2018 и их предпочтениям. Буду смотреть есть смысл краудфандинг делать или нет.

Помнится, еще archimag писал о том, что поигрался с идеей описания веб-документа с помощью макросов на лиспе, но отказался, как от бесперспективной.

И написал на лиспе компилятор макросов JS c фигурными скобочками.

Как будто что-то плохое.

Тема достойная 31 декабря 2017 года. У Вас каждый вопрос - это тема для диссертации...

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

Для этого нужен широкий кругозор уже существующих языков, их плюсов и минусов. Т.к. все новые - это как правило попытка совмещения в одном продукте плюсов предыдущих.

1. Нужны ли классы? Мне нравится прототипное программирование и я не понимаю, зачем тогда нужно класс-ориентированное. Какие преимущества даёт класс по сравнению с прототипом?

Одна из разниц там в том, каким образом сказывается изменение класса или прототипа на наследниках. Насколько это изменение влияет на предсказуемость всего кода и появление побочных эффектов.

Байт-код или машинный код?

Первое не исключает второе и наоборот. Многие современные ЯП имеют и то, и то.
С,С++ -> clang -> bytecode -> llvm -> native
Rust -> rustc -> bytecode -> llvm -> native
Go -> под капотом транслирует в bytecode своего ассемблера, из которого потом генерирует native-код заданной платформы -> native
Java -> bytecode -> есть\разрабатываются компиляторы в native -> native
Net -> bytecode -> есть\разрабатываются компиляторы в native -> native
Bytecode llvm дает возможность компиляции в любой поддерживаемый target, т.е. можно сделать так: bytecode -> llvm -> wasm (webassembly).

И если первое, то регистровая машина или стековая?

Стековая машина проще в реализации, по ней сделаны java\dotnet. Регистровая сложнее, но чуть побыстрее. См. сравнение, например: https://www.usenix.org/legacy/events/vee05/full_papers/p153-yunhe.pdf

4. Какие посоветуете готовые разработки, которые можно приспособить для своего языка? Компиляторы, виртуальные машины, генераторы парсеров, библиотеки, среды разработки?

llvm. Думаю его легко можно использовать для построения собственного компилятора\интерпретатора. Кстати у него есть в составе lli - directly execute programs from LLVM bitcode ( https://llvm.org/docs/CommandGuide/lli.html ).

Видел на хабре пост о создании яп на llvm на с++ но там автор забыл указать, какие файлы из llvm надо подключать в проект, а в документации я что-то не нашёл. Может быть кто-то в курсе?

Оригинальная документация http://llvm.org/docs/tutorial/ По-моему там есть полные исходные коды примеров.

http://llvm.org/docs/tutorial/LangImpl01.html

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

«Когда я была молодой и красивой, а мужчины джентльменами» (с)

Так это и есть та статья, на которую я дал ссылку, только на англ.

Я ожидал увидеть в коде что-то вроде

#include <llvm>

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

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

Ага, а я в 12 лет уже роман писал и мечтал о карьере писателя.

ну и где результат? а я с 10 лет как начала программировать, так до сих пор программистом работаю. есть разница, однако.

Ну не сложилось, журналистка обсмеяла мое произведение. Это разрушило хрустальную детскую психику и я все сжег, решил, что мне не стать писателем :)

С тех пор, если я что-то пишу, то не называю себя писателем или программистом.

http://llvm.org/docs/tutorial/LangImpl02.html#full-code-listing

#include "llvm/ADT/STLExtras.h"
#include <algorithm>
#include <cctype>
#include <cstdio>
#include <cstdlib>
#include <map>
#include <memory>
#include <string>
#include <vector>

http://llvm.org/docs/tutorial/LangImpl03.html#full-code-listing

#include "llvm/ADT/APFloat.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/IR/BasicBlock.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/DerivedTypes.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/IRBuilder.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/Type.h"
#include "llvm/IR/Verifier.h"
#include <algorithm>
#include <cctype>
#include <cstdio>
#include <cstdlib>
#include <map>
#include <memory>
#include <string>
#include <vector>

С++, создание и использование класса:

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

Тут даже дело не в самом классе, а в понятии «тип». Тип - это некое описание структуры. И разница между жс и С++ - это именно то, что в жс структура свободная.

И тебе надо понять то, что в жс нет типов - объект это уже инстанс, а в С++ класс - это не его инстанс.

Ты пытался рассуждать об пациентах, свободной структуре, но ты не учитываешь одно важное но. Это то, что свободная структура НЕ ИМЕЕТ смысла, именно в рамках использования её в программе. Почему?

Всё очень просто, для интерпретации любого объекта - у тебя в код должна быть заложена его структура. А код ВСЕГДА статичен. Это значит, что если ты хочешь вставить в своего студента новое поле - тебе надо изменять его обработчики, ведь иначе - его никто не увидит.

Именно поэтому, отсутствие типизации не есть свобода, а есть ограничения. Ты не получаешь ничего, но теряешь множество возможностей. В частности, тип - это некий контракт, который обязаны исполнять обработчики/создатели одно и того типа объекта. И ты обязан ему следовать, даже в жс. Но у тебя нет средств для этого, а это полная жопа.

Свобода предполагает не только свободу от ограничений, но и свободу ограничений.

В общем, если копнуть глубже - ты пытаешься решить ту проблему, которую не осознаёшь, либо даже не пытаешься, а я тебя этим наделил. Да и это неважно.

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

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

Как это происходит сейчас. Ты можешь объявить класс, ты можешь от него унаследоваться и добавить в него что-то, создав новый класс. Сам класс ты изменять не можешь, но тебе ничего не мешает это реализовать.

Что позволяет с делать жс, но не позволяет сделать C++? Ты не можешь взять и заинжекстить в некий класс некую логику с нужными данными. Да, ты можешь накастылять лапши, но это никогда не будет выглядеть удобно и нормально.

В жс ты помешаешь просто подменять прототип и таким образом инжектить функционал в объекты. Правда, ты никогда о нём не узнаешь, как и о всём то, что лежит у тебя ниже/выше. И все этого боятся именно по этой причине - это магия, а магия плоха не потому, что она магия, а потому, что её невидно.

В статическом же варианте - у тебя всё это видно и никаких проблем нет.

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

Хотя естественно, ты мог бы решить это через наследование, но зачем - когда можно пользоваться магией, как в жс.

В конечном итоге, к чему это я. А к тому, что всё это можно решать статически, но это задача совершенно иного класса сложности и это именно то, что нужно пацанам, как и пользователям того, что они наваяют.

Тут дело в том, что ты, скорее всего, как-то криво понимаешь «интуитивно». Интуитивно это тогда, когда ты понимаешь как делать, понимаешь - как это работает. Интуитивно - это не просто, интуитивно это тогда, когда есть чёткая логика, которую любой человек( способный её понять) - может понять, а далее все нюансы достроить сам.

И проблема в том, что если ты не понимаешь - ты не понимаешь. И то, что интуитивно - точно так же будет сложно. Подавляющие большинство людей не понимает, а заучивает. Они не понимают, что значит каждая закорючка и почему она там берётся - они просто заучивают паттерны.

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

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

Описывать ограничения очень сложно - это полностью и досконально понимать то, что ты описываешь. Иначе у тебя будут дыры, либо ты переборщишь с ограничениями.

Все мечтают о том, что появится какой-то супер-язык, который будет всё делать, на котором ты будешь писать любую херню и он каким-то образом её будет проверять. Нет, так не бывает.

Если я понимаю то, к чему у меня есть интерфейс. Я понимают то, как он должен выглядеть и почему и что в нём надо ограничить. Для жс-адепта это будет просто 100к строк лапши, в которой он никогда не разберётся и не поймёт. Он будет тебе орать - зачем она мне.

Люди просто не привыкли думать, структурировать свои знания и то, что из под низ рождается. Ты их этому не заставишь, да и никак хаос нельзя структурировать.

Так работает мир - халявы в нём не бывает. Ты должен что-то вложить, чтобы что-то получить. Хочешь профита от структурированности? Научись её строить и понимать.

Просто пример. Есть Вася на складе, у которого всё валяется всегда в дерьме и хрен пойми где. Заставили Васю перейти на новую супер-современную систему, но вот незадача.

Васи теперь надо не просто кидать всё куда он захочет, а кидать туда, куда нужно. Ему нужно запомнить/понять то - куда это нужно кидать. Нужно понять структуру стеллажей, чтобы не заблудиться в них.

И казалось бы - сделав это Вася сэкономит 80% своего времени, ведь он будет искать что-то в помойке каждый раз по пол часа. Но он немного теряет в другом - нельзя просто что-то кинуть куда-то, надо потратить месяц на новое.

И в этом проблема - никто этого не хочет делать. Люди не понимают, что это что-то им даст, а даже понимая - не хотят. Отговорки можно найти всегда, но суть в том, что это всё только отговорки.

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

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

Я был бы рад, если бы кто-то мне рассказал и показал то, что я не понимаю. Но вы, похоже, как-то иначе устроены. Вам это не интересно.

Я задал вопрос «как грамотно и качественно создать ЯП» - я получил ответ, по подтемам я тоже получил ответы. То что я хотел узнать, я узнал. Так о чём ещё разговаривать?

Нет, лисп это не пример. Причина проста - лиспа не существует. Это типичный брайнфак. Это полностью несостоятельная концепция, а то, что называется лиспом - им не является. Это типичный пример подмены понятий.

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

Интуитивность и общность - это не значит ограниченность. Это не значит сведения к одному. Это значит лишь объединения всего общей логикой, либо набором логик. Ограничить всё одной конструкцией и парой протухших мантр - это не то, что нужно.

Допустим, люди попросту не понимают, что такое указатели в сишке, почему они такие, почему тип переменной-указателя всегда один. Почему тип, который пишется рядом с указателем - не имеет никакого отношения к типу переменной. Люди не пытаются понять то, с чем работают. Они пытаются учить формализацию 10 раз прошедшую через глухой телефон.

Не понимания этого - они не понимают, почему нету типизации на уровне типов указателей. Это придумали себе какую-то другую логику, и пытаюсь в неё засунуть реальность.

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

Допустим, когда-то давно я срался с людьми на тему того, чем является = {} в сишке. Естественно, что никто и никогда не будет читать стандарты, да и мало там что есть относительно «почему» - есть только «как». И под это как можно подбить сколько угодно решений, но почему именно так - никому не интересно.

Ну дак в чём заключались срачи - в том, что я утверждал, что = {} - если не инициализация, а есть создание объекта и приравнивание его левой части.

Тут было много проблем с тем, что у нас есть массивы, которые не копируются. И это можно использовать как пруф того, что это именно инициализация. Но тут то же есть нюансы, а вдруг логика была в том, что массивы можно приравнивать только один раз, а вдруг массив - это не массив, а просто указатель на этот созданный объект. Это то же интегрируется в логику.

В конечном итоге, я считая это за объект, который лишь вывод тип из типа того, к чему его присваивают. Далее возникает резонный вопрос, а если он автоматически выводит тип, то почему нельзя задать ему тип явно? Как ему задать тип? Правильно - кастом. Таким образом мы и изобретаем то, что уже есть.

Это и есть интуитивное понимание. Когда язык следует и развиваться с рамках какой-то логики, которую автор может и не осознавал явно, что вряд ли, конечно.

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

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

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

У нас есть си, который динамический язык, логика которого на 80% завязана над тем, что под капотом. Кресты же - это язык, который должен быть строг, должен быть поверх этой логики, должен обладать некой целостностью.

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

И такое везде. И это проблема.