LINUX.ORG.RU

паттерны для правильного (и типизированного) JavaScript

 ,


0

3

Навеяно горячими стримами Мурыча. Я вот задумался: а ведь действительно, можно обойтись без TypeScript, если придумать удобные паттерны для JavaScript. Не хватает двух вещей:

  • Типизации на входе и на выходе, внутри тел функций и у констант она избыточна.
  • Интерфейсов. Для классов можно использовать наследование, но для объектов уже надо думать над валидаторами.

Без остального сахара можно обойтись.

Первое можно решить с помощью optional, как в Java. Можно написать один обработчик для всех типов (с методами getString, getInt и т. д.), или разные. Привязать к синглтону, чтобы мочь глобально отключать проверки в рантайме (например, по флагу в env). Так мы получаем удобные подсказки в редакторе и работающую проверку типов.

Вот с интерфейсами для Object / Array / Set / Map сложнее. Думаю, нужно поэкспериментировать с optional, чтобы на выходе тоже дёргались типизированные методы.

А чтобы получить типизированные интерфейсы для классов, просто наследуемся от типизированного родителя: где на входе и выходе методов optional, а тело просто делает throw new Error('not implemented').

Теоретически, это всё можно запихнуть в библиотечку. Но не знаю, дойдёт ли у меня до такого, я очень задолбался и могу разве что на своих проектах поэкспериментировать, когда (хз когда) такая возможность представится. Может, кто из ЛОРовцев осилит. Ну и высказывайте свои идеи, чтоб собрать их в кучу.

Хочется изобрести рабочую методологию для написания больших и запутанных проектов, а не использовать костыли вроде TypeScript. Это не кажется невозможным. Или может она уже есть, а я о ней не знаю? Из известного нравится подход Тимура Шемсединова: чистый JS с *.d.ts декларациями. Но это не совсем то.

★★★★

Последнее исправление: InterVi (всего исправлений: 2)

Ответ на: комментарий от static_lab

чтобы заценить широту спектра…:)

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

alysnix ★★★
()
Ответ на: комментарий от static_lab

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

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

Мне кажется, «семантическая сложность» программы не эквивалентная объёму машинного времени, затраченному на выполнение этой программы. И, кстати, если взять условный компилятор C++, то важную часть в нём будет занимать синтаксический анализатор, а он генерируется из декларативного описания синтаксиса языка, потому что написать его вручную невероятно сложно.

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

Вот несколько аспектов, которые могут влиять на семантическую сложность программы:

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

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

Модульность: Хорошо структурированный код с разделением на модули снижает сложность, поскольку каждый модуль имеет четко определенную задачу и ответственность.

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

Глубина вложенности и сложность алгоритмов: Чем больше глубина вложенности и чем сложнее алгоритмы, тем выше семантическая сложность программы.

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

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

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

Мне кажется, «семантическая сложность» программы не эквивалентная объёму машинного времени, затраченному на выполнение этой программы.

конечно не эквивалентна. семантически простейшие операции умноженные на огромное число их повторений, могут требовать огромных выч. ресурсов (память+время).

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

Вы опять передёргиваете термины. Семантическая сложность означает сложность самой программы на том языке, на котором она написана. И эта сложность может не отражать алгоритмическую сложность программы. Например, тупое решение задачи с Литкода может иметь алгоритмическую сложность O(n^2) или даже O(n^3), но при этом семантически оно будет простым и понятным, в каком-то смысле повторять текст задачи. А вот эффективное решение с линейной или логарифмической сложностью будет скорее всего нетривиальным и требовать много времени и знаний на написание или понимание такого кода.

По этой причине, неэффективный код на C++ может проигрывать даже оптимизированной реализации на Питоне, несмотря на то, что сам интерпретатор Питона написан на Си.

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

неэффективный код на C++ может проигрывать даже оптимизированной реализации на Питоне

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

берете один и тот же алгоритм, требовательный к ресурсам, реализуете на с++ и питоне/js. и сравниваете.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

берете один и тот же алгоритм, требовательный к ресурсам, реализуете на с++ и питоне/js. и сравниваете.

Так мы будем сравнивать вообще-то производительность языков. Я так понимаю, что это ваш единственный аргумент в отношении C++ как «труЪ языка программирования».

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

Например, язык RPGLE для мейнфреймов IBM позволяет работать в тесной связке с базой данный IBM DB/2. Одной командой можно определить структуру данных, эквивалентную записи в таблице этой базы. Более того, при запросе записи база тупо скопирует байты с диска и пришлёт их в программу «как есть», а программа на RPGLE будет читать поля записи как свои родные типы данных. Разумеется, скомпилированный машинный код будет для данной задачи крайне эффективным. В случае с C++ для подобной эффективности понадобится гора врапперов, либо придётся каждый раз вручную ковырять байтики, что приведёт к семантически сложному и неподдерживаемому коду.

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

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

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

alysnix ★★★
()
Ответ на: комментарий от static_lab

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

ну вот с++ компилятор - семантически сложен. его алгоритмическую сложность сами определяйте.

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

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

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

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

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

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

о какой поддержке идет речь, если скриптовые языки в большинстве своем нетипизированы. потому что их удел и настоящее предназначение - работать в консоли, бодро отвечая сколько будет 2+3. а тут типы не нужны и вообще избыточны.

потому и приходится пришлепывать типизацию сверху(Type script), чтобы не запутаться в больших проектах, куда тянут за уши эти консольные арифмометры дяди из корпораций.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

А что, если языки по-настоящему общего назначения — это как раз высокоуровневые языки aka скриптуха, а низкоуровневая байтота с педальной сборкой мусора — это специализированные языки для написания компиляторов/интерпретаторов нормальных высокоуровневых языков?

Возьмём, к примеру, ассемблер и жопаскрипт. На чём можно написать более сложную и фичастую программу при тех же ресурсах (время, деньги на найм работников и т.д.)? Ответ очевиден.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Nervous

а низкоуровневая байтота с педальной сборкой мусора — это специализированные языки для написания компиляторов/интерпретаторов нормальных высокоуровневых языков?

железный конь пытона и жиэс идет на смену крестьянской лошадке с++!

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от Nervous

Ничего никуда не прочтётся, в исходниках описаны схемы

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

например, произвольные предикаты в схему не втулить

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

special-k ★★★
()
Ответ на: комментарий от alysnix

языки програмирования это с++, java, ада

дрочить на самого себя как-то не очень

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

special-k ★★★
()
Ответ на: комментарий от alysnix

типизацию сверху(Type script), чтобы не запутаться в больших проектах

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

special-k ★★★
()
Ответ на: комментарий от alysnix

или просто нет выбора(типа как js в браузере)

А как так вообще вышло, что все нужно запустить в браузере, от бухучета до графических редакторов?

Вообще-то выбор есть. В 2012 году вышел Dartium, который умел запускать строго типизированный Dart. Также есть wasm. Но что-то не взорвала сообщество возможность типизации.

special-k ★★★
()
Ответ на: комментарий от Nervous

Так ничто не мешает написать компилятор интерпретатора php на php и тд. Не понимаю суть претензий. Да и самих низкоуровневых языков не существует: есть ассемблер, есть операционка, которая команды выполняет… Все фикция, епта. Ну мля я не понимаю какой смысл пейсать типа язык X написан на языке Y по факту это ж не так, там от этого языка ничего нет, потому что и тот язык ничто… У нас операционка, котрая эмулирует многозадачность - единственная выполняемая программа, которая эмулирует выполнение других… Ну епта ты ничего не решаешь, все за тебя решают дядя билли и дяди куннилинус ряяяяя… Вот они захотят и запретят твой сранный питон у тебя запускать

anonymous
()
Ответ на: комментарий от Nervous

И вообще все эти чмошники: растоманы, яваобрыганы, матанозадроты с хаскелем, сишные снобы и прочие говноеды - клинические идиоты. Они не понимают что с точки зрения дяди билли и дяди кунилинуса они всего лишь жалкие макаки ничем не лучше «программиздов» экселя… Так что чсв им бы на 0 поубавить, а то ведь по факту яваскрипт, который выполняется в браузере - ага в одной единственной программе по факту лишь рекурсивное отражение поделий сишкомакак, которые так же выполняются в одной программе - операционке ага… Если бы боги почаще сходили на землю, то они бы поржали с драм местных дурачков из-за тупизации и религиозных войн о том какой же язык самый правильный ряяя

anonymous
()
Ответ на: комментарий от anonymous

Кароч, совет от большой компании в машинном переводе:'''Скомпилируй главное компилятором ГАК, не забудь выставить флаг сварка ''' Торопись, курсы приема анонимусов ограничен в их школу!

anonymous
()
Ответ на: комментарий от anonymous

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

В линуксе хватит утилит, палочек |, и этих, как их там галочек ```<<``!

anonymous
()
Ответ на: комментарий от special-k

Также есть wasm. Но что-то не взорвала сообщество возможность типизации.

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

а верно - гнать в браузер готовый бестиповой код вирт машины… видимо оно wasm и есть. не знаю что там с типами у него, но они уже не нужны.

alysnix ★★★
()
Ответ на: комментарий от alysnix

а верно - гнать в браузер готовый бестиповой код вирт машины… видимо оно wasm и есть. не знаю что там с типами у него, но они уже не нужны.

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

FishHook
()

optional, как в Java.

Не надо тащить из жаба везде эту ооп парашу я вас умоляю

Типизации на входе и на выходе, внутри тел функций и у констант она избыточна.

Функцию определяешь декларативно:

makefunction({
  args : { /* type definition */ },
  return : { /* return definition */},
  inject : { /* injections */},
  func : function(args) { ... },
  test : { case : { in : { ... }, out : { ... }, ... }
})
makefunction делает всю магию - проверку типов, тесты, инъекции и что душе угодно, на выходе выдаёт функцию, в которую или вшиты уже все нужные вызовы, или сгенерирован код, если это все будет сильно бить по производительности, или все тесты и проверки просто обрезаны для прода.

Интерфейсов

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

crutch_master ★★★★★
()
Ответ на: комментарий от InterVi

что ещё за makefunction, оно есть в спеках?

Нет конечно. Это функция, которая делает функцию.

громоздкая конструкция

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

crutch_master ★★★★★
()

лучше избыток своих энергий направьте на убеждение сектантов мелкософта, ябла и меты в необходимости принятия Type Annotations в стандарт джаваскрипта и прекращении паразитирования на собственных выкидышах-заменах js (ts, dart, swift). Не читал чего они там понафигачили, но, судя по статусу, год назад очередной раз не приняли.

https://github.com/tc39/notes/blob/main/meetings/2023-03/mar-22.md#type-annotations-proposal-update

Syncro ★★★★★
()
Последнее исправление: Syncro (всего исправлений: 1)
Ответ на: комментарий от InterVi

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

Syncro ★★★★★
()
Ответ на: комментарий от InterVi

он говорит конкретно о typed script, который мне еще поглядеть надо ,ибо я не вебщик.

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

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

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

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

прав. но типизация(в правильном исполнении) всегда лучше, чем нетипизация в лучшем исполнении.

Нет «нетипизации». Есть или типизация во время компиляции или во время исполнения. То, что ты называешь «нетипизации» это просто забили хер и вызывают на авось.

crutch_master ★★★★★
()
Ответ на: комментарий от InterVi

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

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от Obezyan

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

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

InterVi ★★★★
() автор топика
Ответ на: комментарий от InterVi

им мы благодарны за вечно лагающий фронт.

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

V8 быстр потому что использует inline cache на базе object shapes. это значит что для него абсолютно одинаковы следующие объекты:

const object1 = { x: 1, y: 2 };
const object2 = { x: 3, y: 4 };

т.к. объекты в js это словари (dict) с набором пар ключ => значение, а shape проверяет лишь ключи и их порядок в этих самых dict.

Поэтому и не принимают type annotations и прочее, тк это выстрел в ногу по скорости. Медленный js не имеет смысла и не нужен никому.

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

А Мурыч просто сбитый лётчик, который пытается согреться вниманием неофитов.

Obezyan
()
Ответ на: комментарий от Obezyan

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

InterVi ★★★★
() автор топика
Ответ на: комментарий от InterVi

Пока не пришли клоуны, мы их конструктивно обсуждали. По существу есть что сказать?

Никак вы - миддлы, не научитесь… Я предлагаю Вам ради разнообразия подумать: если это реально так просто и не влияет ни на что то почему вместо засовывания декорации\ассертов в отдельные классы сделали целый Typescript? Можно ж было просто классов в js налепить как Вы сделали и подключать в dev окружение?

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

Obezyan
()
Ответ на: комментарий от Obezyan

почему вместо засовывания декорации\ассертов в отдельные классы сделали целый Typescript?

Напоминаю, что JavaScript — это торговая марка. Та штука, которая исполняется в браузере и в ноде, на самом деле называется ECMAScript. А TypeScript это попытка подмять под себя этот самый ECMAScript, пропихнув в него type annotations, прибитые гвоздями к TS. Собственно, вот и весь ответ: потому что тупые и жадные.

Остальное уже обсуждено в начале треда, до прихода клоунов.

InterVi ★★★★
() автор топика
Ответ на: комментарий от InterVi

TypeScript это попытка подмять под себя этот самый ECMAScript, пропихнув в него type annotations

Может, я чего-то не знаю, но TypeScript — это же просто расширенный синтаксис для стандартного JS. Какие-то фичи, типа декораторов, действительно обкатываются в TS перед добавлением в стандарт ECMAScript — но разве это повод вопить про подминают?

Собственно, вот и весь ответ: потому что тупые и жадные.

А по-моему, вполне грамотно отделили статические проверки, которые нужны во время разработки и сборки, от динамических проверок, которые нужны во время выполнения. Сделали так, чтобы статика не мешалась под ногами во время выполнения (и во время разработки, если в ней нет нужды). Сплошные плюсы. Чего ж тебе ещё надо, собака? (тм) %)

Падажжи, они ещё чего-нибудь для динамики запилят.

Nervous ★★★★★
()
Ответ на: комментарий от InterVi

Напоминаю, что JavaScript — это торговая марка. Та штука, которая исполняется в браузере и в ноде, на самом деле называется ECMAScript.

Это Вам на стриме Мурыч так заявил?

Javascript - это язык который примерно соответствует спецификации Ecma 262. А ECMAScript это язык который точно соответствует этой спецификации. Можно назвать Javascript - диалектом ECMAScript. Чистого ECMAScript в природе не существует ни в браузере ни в ноде, он есть только на бумаге - в стандарте.

Есть различные версии, которые по разному покрывают части спецификации Ecma 262 разных версий и имеют свои фичи не описанные в стандарте вообще. Их и называют JS.

А TypeScript это попытка подмять под себя этот самый ECMAScript, пропихнув в него type annotations, прибитые гвоздями к TS.

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

Собственно, вот и весь ответ: потому что тупые и жадные.

Прежде чем так уверенно давать ответ Вам стоит понять вопрос. Не по стримам Мурыча.

Obezyan
()