1. JavaScript / Говнокод #27911

    +1

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    type CreateMutable<Type> = {
      -readonly [Property in keyof Type]: Type[Property];
    };
     
    type LockedAccount = {
      readonly id: string;
      readonly name: string;
    };
    
    type UnlockedAccount = CreateMutable<LockedAccount>;
    
    function main() {
        let a: LockedAccount;
        let b: UnlockedAccount;
    
        print("done.");
    }

    Я вам наговнокодил новую фичу.. называется "mapped type"

    Запостил: ASD_77, 01 Января 2022

    Комментарии (41) RSS

    • ах да.. а ты так можешь говнокодить в С/C++?
      Ответить
      • Это всё херня ограниченная в любом случае, нужно чтоб работа с AST, гомоиконность.
        Ответить
        • Это возможно только в интерпретируемых языках, поэтому, если хочешь перформанс и конпеляцию, придётся терпеть.

          Доказать это утверждение будет домашним заданием.
          Ответить
          • На самом деле нет. Ведь вся хуйня с перестройкой AST может отработать на этапе компиляции, и уже потом всё четко откомпилируется без всяких интерпретаторов, и отлично в контроллеры встраивается. Я это еще в 2017 году писал же
            https://govnokod.ru/23275#comment389295
            Ответить
            • > Я это еще в 2017 году писал же

              Это классика! Это знать надо!
              Ответить
            • > На самом деле нет.

              Вообще-то да.

              > Ведь вся хуйня с перестройкой AST может отработать на этапе компиляции

              Не может, а это единственный вариант.

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

              А это правда.

              Так как компиляция и выполнение программы – два раздельных этапа, невозможно создать гомиконный компилируемый язык. Придётся либо как-то разделять файлы на АСД-питушню, либо для питуления АСД разрабатывать отдельные синтаксические штучки.
              Ответить
              • > Вообще-то да.

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

                > Не может, а это единственный вариант.

                Нет. Не вижу проблемы в том, чтобы программа динамически перестраивала свой AST в процессе выполнения. Можно сделать даже интерпретатор и JiT над этим AST.
                Ответить
                • > Нет. Не вижу проблемы в том, чтобы программа динамически перестраивала свой AST в процессе выполнения.

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

                  > Неинтерпретируемость языка никак не мешает на этапе компиляции работать с его AST.

                  Это правда. Зато неинтерпретируемость мешает работать с АСД на этапе выполнения программы, да и на этапе компиляции добавляет сложностей: приходится вводить новый синтаксис для компайл-тайм вычислений.
                  Ответить
                  • > В скомпилированной программе нет АСД, там машинные коды.

                    Могут и быть. Т.е. в бинарник вполне можно напихать кроме скомпилированных инструкций процессора еще и AST от его исходника, и этот бинарник может в процессе своего выполнения частично себя перекомпилировать, и переписывать себе машинный код таким образом.
                    Ответить
                    • Тогда перформанс очень пострадает, а ещё придётся пердолиться со всяким битоёбством... Даже в крестах легче проект перекомпилировать, чем разбираться с ABI и прочими пердолями, что уж говорить про _переписывание_ машинного кода программы самой собой.
                      Ответить
                      • > Даже в крестах легче проект перекомпилировать, чем разбираться с ABI и прочими пердолями, что уж говорить про _переписывание_ машинного кода программы самой собой.

                        HotSpot VM этим постоянно занимается. В рантайме всякое говно профилирует и перекомпилирует. См. https://ru.wikipedia.org/wiki/Адаптивная_оптимизация
                        Ответить
                        • > HotSpot VM

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

                          > Рассмотрим гипотетическое банковское приложение, которое обрабатывает транзакции друг за другом. Эти транзакции могут быть списаниями, взносами и множеством других непонятных операций. Когда программа выполняется, фактические данные могут состоять из очистки десятков тысяч списаний без единой обработки взноса и без единой обработки списания с мошеннического счёта. Адаптивный оптимизатор будет компилировать в машинный код, оптимизируя его для общего случая. Если система затем начинает вместо этого обрабатывать десятки тысяч взносов, адаптивный оптимизатор перекомпилирует в машинный код, чтобы оптимизировать для новых общих условий. Эти оптимизации могут включать встраивание функций или перемещение кода обработки ошибок во вторичный кэш.

                          Таким образом такие оптимизации всегда будут в языках вроде «Jawa», а скомпилированные такими языками программы будут байткодом для виртуальной машины, которая будет по каким-то мутным эвристикам дополнительно компилировать кусочки байткода в машинный код.
                          Ответить
                          • > Вот именно, что VM. Это инструкции для виртуальной машины, а не какой-нибудь там бинарник.

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

                              Зато я точно уверен, что прослойка в виде виртуальной машины скажется на перфомансе в худшую сторону.
                              Ответить
                              • LLVM IR можно высирать и джитить в рантайме.

                                Т.е. это вполне работает и юзается в местах, где критичен пирфоманс, но заранее какие-то параметры неизвестны (софтварная прыщеграфика, емнип).
                                Ответить
                                • А какой код будет перфоманснее, скомпилированный бесконечно-оптимищирующим компилятором или поджитенный идеальным LLVM-джиттером?
                                  Ответить
                                • > LLVM IR можно высирать и джитить в рантайме.

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

                    Не факт. В крестопарашных constexpr новый синтаксис не вводили. Но там не работают такие замечательные сишные функции, как memcpy(), memset(), malloc() - так что это неполноценная убогая херня, ведь я не могу переиспользовать свой код, в котором эти функции присутствуют.
                    Ответить
                    • > constexpr

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

                          В крестах добавили ключевое слово, в «Nim» добавили много ключевых слов. От этого суть не сильно поменялся, но «Nim» мне кажется более выразительным.
                          Ответить
                          • > в «Nim»

                            В "Nim" нет гомоиконности, так что хуита это. Надо чтоб гомоиконность!
                            Ответить
                            • Так и в «D» нет гомоиконности, получается?
                              Ответить
                              • Именно. Там вот https://govnokod.ru/27615#comment664409 я приводил цитату. Они сами признали свою фатальную ошибку, что не сделали синтаксис однородным, как в LISP.

                                > This is due to the fact that D is not as “regular” a language as Lisp. Some of the people helming the evolution of D are working on changing this, and it is my hope that an improved D will emerge in the not-too-distant future.
                                Ответить
                                • То есть «Lisp» – единственный язык с гомоиконностью?
                                  Ответить
                                  • > То есть «Lisp» – единственный язык с гомоиконностью?

                                    Нет конечно. https://en.wikipedia.org/wiki/Homoiconicity#Implementation_methods - там вот перечислены некоторые языки
                                    Ответить
                                    • Оказалось, этим вопросом уже задавались:

                                      https://stackoverflow.com/questions/1238858/can-a-compiled-language-be-homoiconic

                                      In the most literal form, C is homoiconic. You can get access to the representation of a function using &functionName and execute data using somePtrCastToFnPtr(SomeArgs). However this is at the machine code level and without some kind of library support you will find it very hard to work with. Some kind of embeddable compiler (I seem to remember that LLVM can do this) would make it more practical.

                                      Сишка гомоиконная, получается?
                                      Ответить
                                      • > You can get access to the representation of a function using &functionName and execute data using somePtrCastToFnPtr(SomeArgs)

                                        Сомнительно. Функции вообще могут в другом адресном пространстве находиться, и это адресное пространство может быть даже недоступно для модификации.
                                        Ответить
                                        • Есть ещё вот такой нахрюк:

                                          The problem is that a lot of processors separate instruction and data areas, and actively prevent programs from modifying their own code. This kind of code used to be called "degenerate code", and considered a very Bad Thing.

                                          Interpreters (and VMs) don't have that problem, as they can treat the whole program as data, with the only "code" being the interpreter.

                                          Что ж, видимо, скоро тебе в контроллеры завезут VM, и тебе придётся пересесть на интерпретируемый язык типа йажаскрипта или пэйсона.
                                          Ответить
                                          • > Что ж, видимо, скоро тебе в контроллеры завезут VM, и тебе придётся пересесть на интерпретируемый язык типа йажаскрипта или пэйсона.

                                            У меня на контроллерах нет задач, где надо самомодифицировать что-то в логике.
                                            Ответить
    • але... где все... хачу коменты....
      Ответить
    • Долго ломал голову, пытаясь понять, где тут ключевые слова, а где идентификаторы.

      Итак, во второй строке у нас цикл по всем свойствам, объявленным в базовом типе?
      Ответить
    • В чистом С++ вроде нет. Могу кортеж избавить от ненужных модификаторов.
      Если подключить Reflection TS (или сделать что-нибудь работающее на основе p0707), то можно.
      Ответить
    • а вот таким говнокодом можно поля переименовывать

      type Getters<Type> = {
          [Property in keyof Type as `get${string & Property}`]: () => Type[Property]
      };
      
      interface Person {
          name: string;
          age: number;
          location: string;
      }
      
      type LazyPerson = Getters<Person>;
      Ответить
      • В «Nim» такое можно делать на этапе компиляции, потому что язык компилируемый.

        Если бы можно было такое делать в рантайме, то он был бы медленный.
        Ответить
        • у меня это тоже делается на этапе компеляции
          Ответить
    • вот еще говнокодец

      type RemoveKindField<Type> = {
          [Property in keyof Type as Exclude<Property, "kind">]: Type[Property]
      };
       
      interface Circle {
          kind: "circle";
          radius: number;
      }
       
      type KindlessCircle = RemoveKindField<Circle>;
      
      function main() {
      
          let a: KindlessCircle;
      
          print("done.");
      }
      Ответить
    • У меня в ``Erlang'' подобную питушню можно нагов-някать с помощью ``parse transforms''.
      Ответить

    Добавить комментарий