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

    0

    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
    function main()
    {
    	print("before");		
    
    	try
    	{
    		throw 1;
    	}
    	catch (x: any)
    	{
    		print("catch");		
    	}
    
    	print("end");		
    }

    Самый большей говнокод за всю историю человечества сделан.

    Запостил: ASD_77, 10 Сентября 2021

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

    • дампик для всех страждущих https://pastebin.com/UGvZRnkM
      Ответить
    • SEO пост https://github.com/ASDAlexander77/TypeScriptCompiler
      Ответить
    • и результат работы

      before
      catch
      end
      Ответить
    • И в «Nim» есть исключения, но их можно отключить для перформанса.

      А что там с пкрфомансом в «JS++»?
      Ответить
      • ну особо от C++ не отличается. оптимизацию делает LLVM а не я - так что там все ОК :)
        Ответить
        • Вообще-то LLVM это не волшебная оптимизирующая срань, что туда можно какого-то дерьма накидать, а на выходе будет максимально оптимизированная хрень. Если б это было так, тот же Haskell (который, между прочим, умеет компилироваться через LLVM) уже сравнялся бы по перфомансу с сишкой.
          Ответить
        • ну да, решение на С++ будет раз в двести быстрее аналогичного решения на JS.

          Ну может быть в триста

          Но не больше
          Ответить
          • с каких хренов если JS оптимизируется в ASM и код практически идентичный.. потеря есть только если использовать хреновые обжекты
            Ответить
            • Всё равно будут так называемые «переголовы», когда код на «JS» компилируется в избыточный код на «ASM».
              Ответить
            • > только если использовать хреновые обжекты

              Если писать только на сишном подмножестве JS, то можно добиться сишного пирфоманса?

              Не думаю. Придётся заодно насрать на спеку JS чтобы разрешить UB'ы и аггрессивные оптимизации.
              Ответить
              • А restict и правила алиасинга?

                В JS этих понятий нет в принципе.

                Даже если писать на подмножестве и срать в байт-буфера у оптимизатора будут связаны руки.
                Ответить
                • > связаны руки

                  Ну как... Он всё ещё может забить хуй на спеку и считать, что обращения к Uint32Array никогда не алиасятся с Float32Array.

                  По спеке он таких ужасных предположений, конечно, делать не должен.
                  Ответить
            • К примеру, в JS аргументы функций вычисляются в строгом порядке, слева направо.

              Ты, наверное, забил на эту гарантию хуй и дал LLVM'у поиграться с аргументами по-сишному?
              Ответить
              • > по-сишному

                Ну и как же? Сишка в случайном порядке аргументы обсчитывает?
                Ответить
                • > в случайном порядке

                  Более того, она их перемешивает между собой...
                  Ответить
                  • А как же всякие «call convention»?
                    Ответить
                    • Call convention требуют, чтобы перед call все аргументы были вычислены. Про порядок вычисления они ничего не говорят. Это уже к языку программирования.
                      Ответить
                    • У заинлайненной функции нет никаких колл конвеншенов.

                      Единственная гарантия: тело функции всё-таки будет вычисляться позже, чем её аргументы сайд-эффекты от тела функции всё-таки произойдут позже, чем сайд-эффекты от вычисления её аргументов.
                      Ответить
                      • Есть какая-то фигня про «точки следования» (waypoints). Вот они требуют, чтобы что-то было заранее вычислено.
                        Ответить
                      • > сайд-эффекты от тела функции всё-таки произойдут позже, чем сайд-эффекты от вычисления её аргументов

                        А если во время вычисления аргументов ставится таймер, который сработает через ЧАСОК, но тело функции завершается гораздо быстрее?
                        Ответить
                        • В этом случае сайд-эффект - это создание таймера. Вызовы функций здесь ни при чём:
                          let a;
                          setTimeout(() => a = 5, 3600000);
                          console.log(a); // undefined :\

                          Мне почему-то кажется, что си отработает примерно так же.
                          Ответить
      • а вы ваще представляете какой это гиморой сделать исключения даже на LLVM ? практически не раельная задача
        Ответить
        • Именно поэтому я за Си - там нет никаких исключений.

          Но вообще в самом LLVM есть специально сделанные костыли именно для исключений

          https://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics
          Ответить
          • В MSVC, Borland C, Watcom C есть исключения... но только для Винды, потому что реализованы через SEH.
            Ответить
          • Каких только костылей нет в "LLVM"...
            Ответить
          • не верь тому, что написано в документации. в жизни все по-другому :)
            Ответить
        • Именно поэтому я за Rust (нет)
          Кстати, если поставить себе задачу сделать try/finally (с единственной целью, чтобы перед return изнутри try обязательно выполнялся finally) - там будут те же проблемы?
          Ответить
          • runtime один на всех.. другой не завезли :)
            Ответить
    • добавил статью.. на харбе... но я так понял ее никто не видел и не увидит ... типа это песочница https://habr.com/ru/sandbox/159230/
      Ответить
      • кто-то что-то должно меня кудато пригласить.. но я так догадываюсь что никто и никогда этого не сделает :)
        Ответить
        • У тебя там мало написано. Если и одобрят, тебе в коментах насрут чем-то из серии "И че? А где сравнения скорости? А какие полезные и нужные проекты на этом тупескрипт-компиляторе собираются? А как оно с JS работает?"
          Ответить
          • уже одобрили но видать из-за песочници никто не увидел - и коментить я не могу
            Ответить
      • > Давайте посмотрим в чем разница между кодом С/C++ и таким же кодом на TypeScript.

        > Как мы видим большой разницы между кодом нет

        Какой багор ))))))
        Ответить
      • > но для любителей TypeScript синтаксис С/C++ имеет много ненужных вещей. Например, зачем явно указывать тип переменной если ее тип компилятор может определить сам во время компиляции.

        Есть же слово «auto».
        Ответить
        • появилось слово.. а раньше не было ..
          Ответить
        • во вторых слово авто всеравно надо указывать а в TS нет
          Ответить
          • в "TS" надо указывать слово "let" , а в C++ нет

            Тем не менее я не спорю, что вывод типов в TS сделан намного лучше.


            Но сранивать С++ и TS глупо: это языки для разных задач.

            А вот если сравнивать TS с JS, Ruby, PHP и Python, то я пожалуй соглашусь, что TS выглядит очень хорошо
            Ответить
            • > языки для разных задач

              такая себе мантра. и на js, и на крестах можно написать веб-сервер. и на js, и на крестах можно написать гуйню. да в общем куски фронтенда можно написать на том и на том. в чём разные задачи?
              Ответить
              • Вон там борманд MD5 брутит.
                Перепиши на JS
                Ответить
                • по существу возражений нет? гуд
                  Ответить
                  • Запили на «JavaScript» брут «md5», и чтоб с «SSE» и сотнями мегахешей.
                    Ответить
                    • байтоёб это в 95% мразь, а в 5% просто обманутый человек.
                      Ответить
                      • Да, можно просто купить машину помощьнее.
                        Ответить
                        • ну, можно сидеть на железе двадцатилетней давности, конечно

                          ты ведь именно так и делаешь? ;-)
                          Ответить
                          • Ну т.е. вместо байтоёбства логичнее купить ещё десяток компов. Ок.
                            Ответить
                            • Ну да. Арендуй себе кластер на 1000 ядер. А если писать на JAWA, то понадобится 20000 ядер.
                              Ответить
                              • > 20000 ядер

                                Сколько ядер ни возьми, JAWA встанет раком на сборке мусора, т.к. памяти может не хватить, Jawa же говнище)
                                Ответить
                                • Возьми памяти терабайт на сервер. Или и этого может не хватить?
                                  Ответить
                                  • > In this java program, 1000 threads are created in the ‘FullStackFrameProgram’ class. All the ‘FullStackFrameThread’ threads repeatedly invoke the ‘simpleMethod(int counter)’ for 10,000 times. After 10,000 invocations, threads will go for infinite sleep. Since thread is invoking the ‘simpleMethod(int counter)’ 10,000 times, each thread will have 10,000 stack frames and each stack frame will be filled up with local variables ‘x’, ‘y’, ‘z’.

                                    Боюсь, чем больше ядер, тем больше придётся докупать памяти, ведь JAWA настолько анскильная, что на каждый тред копирует стек!
                                    Ответить
                                    • а ты бы хотел корову там видеть?


                                      Вообще открою страшную тайну: нет смысла иметь тредов больше, чем у тебя ядер
                                      Ответить
                                      • > корову

                                        mootools

                                        > Вообще открою страшную тайну: нет смысла иметь тредов больше, чем у тебя ядер

                                        А если у меня четыре ядра, но они двойные? Можно иметь 8 тредов?
                                        Ответить
                                        • Ну просто если у тебя реально 1000 тредов, то у каждого должен быть свой стек. Максимум что можно сделать это COW.

                                          >двойные
                                          гипертрейдинг?

                                          Сильно зависит от задачи, но в общем случае можно считать их отдельными ядрами
                                          Ответить
                                      • Смысл есть. Например, у меня есть 50 задач с разным интервалом исполнения. Я создаю 50 тредов и не ебусь с тредпулами и шедулингом.
                                        Или более простой пример: 32 треда обрабатывают запросы пользователя, а 1 тред выполняет в фоне таски, в то время как ядер всего 32.
                                        Ответить
                                        • > Например, у меня есть 50 задач с разным интервалом исполнения.

                                          Это для софтварных тредов. На инициализацию хардварных тредов ты потратил слишком много времени.

                                          > 32 треда обрабатывают запросы пользователя, а 1 тред выполняет в фоне таски, в то время как ядер всего 32.

                                          Переключение контекста нынче недёшево...
                                          Ответить
                                        • >Например, у меня есть 50 задач с разным интервалом исполнения.

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

                                          Правда если задачи блокирующие и без блокировки их не переписать, то ты в жопе.
                                          Ответить
                                        • Ладно, перефразирую:


                                          в теории смысла нет, на практике бывает удобнее сделать поток, и не писать МНОГО КОДА для корутин или пула или асинхронщины

                                          Инструменты пока что слабоваты
                                          Ответить
                                      • > Вообще открою страшную тайну: нет смысла иметь тредов больше, чем у тебя ядер
                                        Для CPU-bound задач — да. Для IO (когда тебе надо серануть в сеть/прочитать диск и ждать ответа) — вполне себе имеет.
                                        Ответить
                                        • Это не треды, а софтварные потоки.
                                          Ответить
                                        • Если у тебя есть блокирущий IO, то да.

                                          Но если ты можешь переписать код на select/poll/CompletionPorts то нет смысла держать треды в спящем состоянии.

                                          В котлине есть корутинная либа ktor например, это обертка вокруг тех самых полов.

                                          Если тебе нужно обработать 44 запроса,ты просто создаешь 44 корутины.

                                          Все они работают на тредпуле размером с кол-во ядер.

                                          Если какая-то корутина "блочится", то на самом деле она не блчится, а передает управление другой корутине
                                          Ответить
                                          • > Если какая-то корутина "блочится", то на самом деле она не блчится

                                            Всё, что прикасается к Jawa и JWM – превращается в ложь, обман, предательство и растрату ресурсов компьютерна.
                                            Ответить
                                            • корутины есть в питоне, и в C# и JS

                                              не нравится котлин, возьмите asyncio из питона
                                              Ответить
                                          • > в котлине

                                            Азаза. Jawa-отгрызок пытается хоть как-то повысить перформанс )))))))))
                                            Ответить
                                            • Причём очевидные улучшения не делаются из принципа )
                                              Ответить
                                              • Приведи пример очевидного улучшения, которое можносделать не сломав интероп с JAWA
                                                Ответить
                                            • Там не только перформанс,там еще и структурная конкаренси, когда целое дерево корутин легко грохнуть
                                              Ответить
                                            • Кстати, Kotlin – это проприетарная злобнохуйня, созданная копирастами и пропpиетарщиками из JetBrains, самой лагучей и жручей IDE, т.к. она написана на пиздопротивной JAWA.
                                              Ответить
                            • как говорит guest6, слив засчитан
                              Ответить
                        • Вот что интересно, у вас с Царём, сколько себя помню на ГК, были всегда свеженькие i7-3.1415-K.

                          Я до 2019 для написания и проверки скриптушни обходился ноутбучным i5 третьего поколения. Обходился бы и сейчас, но хромолисовинды оборзели и стали вытекать из 8ГБ, а это уже был максимум, который туда можно было вставить.
                          Если б можно было туда впердолить ещё памяти, хватило бы до 2025 года.
                          Ответить
                          • > свеженькие

                            Да нифига... у меня довольно долго был i5 3570k, купленный ещё до падения рубля. Не ноутбучный правда, так что он и сейчас вполне юзабелен.

                            i7 8700k буквально пару-тройку лет юзаю.
                            Ответить
                  • слив защитан
                    Ответить
                    • http://www.asciify.net/ascii/ascii/12914

                      жаль, в 2000 символов не помещается. плохо Плэнер* Скрепер html-формы разработал


                      * https://ru.wikipedia.org/wiki/Плэнер
                      Ответить
                • На самом деле можно попробовать перевести на вебасм и сравнить.

                  В 8 раз точно сольёт, avx то нету. Но может хоть до уровня опенссл дотянет...
                  Ответить
                  • а SSE в вебасме есть? а нет API браузера для хешей?
                    Ответить
                    • Пишут, что есть экстеншен для 128-битных векторов. Х.з. правда какие там инструкции поддерживаются.
                      Ответить
                      • я ваш вебазм вообще не знаю

                        Там можно не срать в кучу, например? А инты нормальные там есть?
                        Ответить
                        • Там нет кучи...

                          Там есть инты, флоаты, линейный кусок памяти и отдельный массив для указателей на функции. В общем-то больше там нихуя нет, даже неструктурных jmp'ов.

                          Дейкстре бы понравилось.
                          Ответить
                          • какая машина тюринга)))

                            я почему-то думал это JVM, а это весьма годно
                            Ответить
                            • Меня структурное control flow бесит. Я понимаю зачем так сделано, но всё равно бесит. Привкус джавы.
                              Ответить
                              • по заветам дейкстры же, илия тебя не понял?
                                Ответить
                                • Да, только ветвления и циклы с break/continue. Какой-нибудь конченный автомат с произвольными переходами уже не нарисуешь.

                                  Ассемблер со вкусом джавы.
                                  Ответить
                                  • Где-то была статья, где чувак написал конечный автомат с goto, и предложил переписать его без goto.

                                    И кто бы ни пробовал его переписать -- получалось нечитаемое говно ))
                                    Ответить
                                    • > кто бы ни пробовал его переписать -- получалось нечитаемое говно

                                      Ну это как с тредом, где сишную обработку ошибок через goto пытались переписать без него. Получалось только хуже и нечитаемее.
                                      Ответить
                                      • Именно потому я за кресты с исключениями
                                        Ответить
                  • как насчет WebCL :)? (т.е. расчетного шейдера?)
                    Ответить
                    • Да там поди такие же анальные ограничения как в webgl...
                      Ответить
                • не сильно сложно LLVM уже дает бэкенд для векторов. просто нужно залабать расширение языка для этого. пока TSC не пойдет раньше времени пижиться нет смысла
                  Ответить
                  • Х.з., в теории всё красиво, а на практике даже в гцц со шлангом векторизатор обсирается, приходится носом тыкать в интринсики...
                    Ответить
            • > вывод типов в TS сделан намного лучше
              ???????
              Ответить
              • юнионы всякие?

                хотя это же не вывод типов, это система типизации другая
                Ответить
              • ну вот ASD привел пример там ниже
                Ответить
            • где тут авто или лет?

              function f(a = 0)
              {
                return a;
              }
              Ответить
              • >Тем не менее я не спорю, что вывод типов в TS сделан намного лучше.


                Хотя конктерно это пример спорен. Я не уверен, что хочу широёбиться по функции ища что она возвращает
                Ответить
                • не надо это делать intellisense давно все знает сам
                  Ответить
                  • Код, который невозможно читать без IDE, не нужен
                    Ответить
                    • а нужен ли тот кто не умеет читать код :)?
                      Ответить
                      • Тебе деньги платят за то, что ты пишешь или читаешь код?)
                        Ответить
                        • Мне деньги платят за то, что я поддерживаю некоторый список хуень и добавляю туда фичи. Нужно ли там писать или читать код - мало кого ебёт.
                          Ответить
                          • Ну да, ты решаешь задачи. Если для этого не надо писать и поддерживать код -- так даже лучше!
                            Ответить
                            • > Ну да, ты решаешь задачи

                              Да он школьник, делает домашку, ололо школоло на говнокоде!
                              Ответить
            • задачи разные это когда не было моего компилятора TypeScript (AOT) Native. теперь его можно юзать вместо с или с++
              Ответить
              • Да, ты точно аутист какой-то

                раз считаешь что кто-то твой тупсрипт будет реально юзать заместо крестов и сишки, при наличии того же Rust, Nim, D
                Ответить
                • Rust говно и хуйня, кстати. Не намного лучше JAWA.
                  Ответить
                  • D тоже гавно. и всегда им было
                    Ответить
                    • Не знаю про «D», но «Nim» это круто, пиздато и охуенно.
                      Ответить
                • луддиты вообще с трудом с машины тюринга еле слезли.... но есть прогрессивный слой людей на земле которые знают что и зачем
                  Ответить
    • кто нить может меня пригласить на хабре... хочу покоментить там :)?
      Ответить
      • Они узнают, что ты пришел с говнокода, и сольют тебе карму.
        Ответить
        • А мы узнаем что он сидит на хабре и засмеём его.
          Ответить
        • нельзя слить то чего нет :)
          Ответить
          • Можно... Будешь потом с кредитной кармой жить.
            Ответить
            • Помню, там у andoriyu крутая карма была:
              http://web.archive.org/web/20120124144026/habrahabr.ru/users/andoriyu/

              Он на всех сайтах умудряется наживать врагов.
              Ответить
              • > –2-й в рейтинге хабралюдей

                А кто -1-й?

                > Откуда: США, California, Santa Barbara

                Ого
                Ответить
                • Да, он даже в конкурсе мудаков занял второе место.

                  К сожалению, вебархив не сохранил 7157-ю страницу рейтинга. Хотя можешь посмотреть, кого утопили в 2007-м:
                  http://web.archive.org/web/20071013092534/http://habrahabr.ru/people/unhabred/page1/
                  Ответить

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