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)
Ответ на: комментарий от 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

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

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

special-k ★★★★
()