Говнокод: по колено в коде.

• Все
• Лучший
• Сток
• Глупый поиск
• Наговнокодить!
• Oтзывы

Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!

1. PHP (5703)
2. C++ (2740)
3. Куча (2339)
4. JavaScript (2030)
5. C# (1930)
6. Java (1503)
7. Си (1103)
8. Pascal (649)
9. Python (585)
10. 1C (536)
11. SQL (434)
12. ActionScript (294)
13. Objective C (204)
14. bash (200)
15. Perl (196)
16. Assembler (148)
17. Ruby (144)
18. VisualBasic (140)
19. Lua (51)
20. Go (32)
21. Swift (29)
22. Haskell (28)
23. Kotlin (15)

1. Куча / Говнокод #20044

   +6

   1. 1
   2. 2

   Что вообще за херня, почему для каждого язычка(рантайма) делают свой пакетный менеджер? pip, npm, cabal, Quicklisp, opam, nuget, NPMчо там еще?
   И притом все они считают что для языка %LanguageName% всенепременно надо писать пакетный менеджер на нем самом.

   Вот например когда я что-то устанавливл через pip, какая-то там херня требует openssl-devel. И узнаю я это только по ошибкам компиляции, ну т.е. там какая-то поебень криптографическая вызывается из питона, оно при установке компилирует через GCC некое говно которое инклудит какое-то .h говно от openssl, но поскольку этого .h нет, оно обламывается на этапе компиляции. Какого хера я про это должен узнавать только на этапе компиляции блядь? Какого хера я должен вручную разруливать эти говнозависимости? А если например будет программа на руби которая использует программу на лиспе, которая использует программу на хаскеле использующую программу на окамле, то что мне, всю эту поеботу тоже руками разруливать по цепочке?
   

   https://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/

   
   какие-то уебни еще сравнивают, какой язык имеет лучший пакетный менеджер... Мудачье! Кто вам сказал что делать для каждого ёбаного языка свой пакетный менеждер это хорошая идея и что среди них может быть "лучший"? Они все говно по определению. Нужно или некое стандартное API для общения между разными пакетными менеджеры разных языков, или один единый пакетный менеджер для всего и под все ОС(а не только Gentoo).

   Запостил: j123123, 19 Мая 2016

   Tweet

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

   • zenn1989 19.05.2016 10:57 # 0

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

     Ответить

     • j123123 19.05.2016 11:00 # +4

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

       Ответить

     • 3_14dar 20.05.2016 14:03 # 0

       >ваш говнокод
       Секундочку, тут речь идет как раз о пользователях, ставящих чужой софт.

       Ответить

   • roman-kashitsyn 19.05.2016 11:08 # +3

     Repeat after me: “Cabal is not a Package Manager”
     https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/

     Ответить

   • roman-kashitsyn 19.05.2016 11:11 # 0

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

     Ответить

     • j123123 19.05.2016 11:41 # +2

       А почему никто не хочет идти к некоему единому стандартному пакетному менеджеру, в рамках которого можно было бы прозрачно разруливать зависимости между разными языками программирования? Английский язык например отлично выполняет роль "общего" языка для всяких там айтишников с разных стран, и проблем это не создает.
       
       И почему opam написан на окамле, QuickLisp на лиспе, npm на жабаскрипте, pip на питоне и так далее, зачем к каждому языку писать пакетный менеджер именно на нем? Неужели все они искренне убеждены в том, что именно их язык самый лучший чтобы писать на нем пакетный менеджер к нему же?

       Ответить

       • roman-kashitsyn 19.05.2016 11:48 # +1

         > Неужели все они искренне убеждены в том, что именно их язык самый лучший чтобы писать на нем пакетный менеджер к нему же?
         
         Просто непостижимо, почему сообщества языка X заинтересовано в написании пакетного менеджера на языке X. Может потому, что они хорошо знают X и считают язык X хорошим, раз вкладывают в него время и усилия?
         
         А почему в каждом дистрибутиве линупса свой собственный универсальный пакетный менеджер, с нестандартизированным именованием пакетов и идеологией?
         
         Кто с кем должен собираться и писать "универсальный стандарт упаковки софта 15.0"? Что это изменит? Все дистры линупса резко пересобирут пакеты, виндовс добавит уберменеджер в стандартную поставку?

         Ответить

         • j123123 19.05.2016 12:03 # +1

           >Просто непостижимо, почему сообщества языка X заинтересовано в написании пакетного менеджера на языке X. Может потому, что они хорошо знают X и считают язык X хорошим, раз вкладывают в него время и усилия?
           
           Может быть есть такие языки, которые лучше других подходят для задачи написания пакетного менеджера, и лучше использовать их?
           
           >А почему в каждом дистрибутиве линупса свой собственный универсальный пакетный менеджер, с нестандартизированным именованием пакетов и идеологией?
           
           Не в каждом свой. Centos, Fedora, OpenSuse, Redhat, ALT Linux - rpm. Debian, Ubuntu, Mint - deb. С дистрибутивами ситуация явно лучше.
           
           >Кто с кем должен собираться и писать "универсальный стандарт упаковки софта 15.0"?
           
           В Linux Standart Base. Наверняка это все можно организовать, только всем похуй
           
           >Что это изменит? Все дистры линупса резко пересобирут пакеты, виндовс добавит уберменеджер в стандартную поставку?
           
           Как минимум мне не надо будет искать ошибки компиляции питоноговна которое зависит от сишных библиотек и ручками доставлять пакеты из репозиториев

           Ответить

           • roman-kashitsyn 19.05.2016 12:13 # 0

             > rpm
             > deb
             
             Это не пакетные менеджеры, это форматы пакетов. Более того, даже пакеты одного формата (например, RPM), зачастую подходят для использования только на каком-то одном дистре, или на каком-то одном РЕЛИЗЕ дистра.
             
             Даже если речь идёт о rpm / dpkg, то это тоже не полноценные установщики пакетов. Они не умеют автоматически разрешать зависимости, скачивая что-то из интернета. Они только устанавливают то, что уже скачано.
             Я как-то жил на системе с одним только rpm, это БОЛЬ.
             
             Люди используют apt-get, apt-rpm, aptitude, yum, smart, zypper, dnf, ... ну вы понели. Зоопарк.

             Ответить

           • roman-kashitsyn 19.05.2016 12:14 # 0

             > В Linux Standart Base.
             
             Пф.... Ну приняли они когда-то RPM в качестве официального стандарта. Ничего не изменилось, всем похер. DEB пакетов уже тогда была в 2 раза больше, никто не будет всё переопакечивать.

             Ответить

           • roman-kashitsyn 19.05.2016 12:17 # 0

             > Может быть есть такие языки, которые лучше других подходят для задачи написания пакетного менеджера, и лучше использовать их?
             
             Почему Haskell плохо подходит для написания пакетоного менеджера? Почему CL плохо подходит? Почему Python плохо подходит (на нём, собственно, большая часть линупсовых менеджеров и написана)? Что не так с JS с асинхронной подсистемой IO?

             Ответить

             • j123123 19.05.2016 12:37 # +3

               Надо спрашивать не "почему X не подходит для написания пакетного менеджера" а "на каком языке лучше всего писать пакетный менеджер". Например, если кто-то чисто теоретически создаст пакетный менеджер для ассемблера, он же не будет настолько ебанутым, чтобы его писать на ассемблере? Или будет?
               
               Какие вообще вещи должен уметь делать пакетный менеджер, если он например из исходников собирает? Разруливание зависимостей между разными версиями разных библиотек, допустим что библиотека X хочет библиотеку Y версии не ниже 1.23 а библиотека Y хочет библиотеку Z версии не ниже 3.33, в то время как библиотека Z хочет библиотеку X версии не ниже 1.33 если ее собирать с поддержкой функции FOO которая нам нужна. ОППА! Circular dependency.
               Относительно частое явление в Gentoo. Можно поставить Z без функции FOO и потом собрать Y и X после чего пересобрать Z с функцией FOO, например. И хороший пакетный менеджер должен уметь это разруливать в автоматическом режиме. Задачу можно сформулировать в терминах ... эээ ... графов зависимостей? Выполнимости неких условий? А почему б не использовать для этого SAT/SMT солверы? Ну вот на вход солверу задаем того, чего мы там хотим достичь(собрать такой-то пакет из исходных кодов), он может выдать некое решение, или даже несколько возможных путей достижения поставленных целей. Можно добавить неких ограничений, например "попробуй-ка разрули тут зависимости, не ставя пакеты A B C" и тогда решатель должен решать с учетом этих ограничений. SMT солверы используются хоть в одном пакетном менеджере?

               Ответить

               • roman-kashitsyn 19.05.2016 12:44 # 0

                 В cabal и opam точно используются, в основном доморощенные. Кто-то даже пыптался прикрутить Z3 к кабалу
                 

                 https://github.com/haskell/cabal/issues/1783
                 https://opam.ocaml.org/doc/Specifying_Solver_Preferences.html#HowdoIexpressmypreferences

                 Ответить

                 • j123123 19.05.2016 12:51 # 0

                   Лучше б сразу why3 прикрутили, тогда б кучу SMT солверов одним махом поддерживать можно было б

                   Ответить

             • j123123 19.05.2016 12:41 # 0

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

               Ответить

               • roman-kashitsyn 19.05.2016 12:45 # 0

                 > хорошо подошел
                 Для асинхронного IO, ага.

                 Ответить

                 • j123123 19.05.2016 12:49 # 0

                   а сильно ли нужен асинхронный IO в пакетном менеджере?

                   Ответить

                   • roman-kashitsyn 19.05.2016 12:59 # 0

                     Если тебе нужно обновить 200 пакетов, зачем ждать их синхронной загрузки, к тому же, если пакеты на разных серверах?

                     Ответить

                     • j123123 19.05.2016 13:08 # +2

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

                       Ответить

                 • wvxvw 19.05.2016 14:21 # +1

                   Ну так и в ж.скрипте асинхронный воод/вывод реализован не силами ж.скрипта. А так, в SWI есть и низкоуровневая многопоточность, и библиотека (как минимум одна), которая реализует что-то типа CSP.

                   Ответить

         • 1024-- 19.05.2016 20:03 # 0

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

           Ответить

           • bormand 19.05.2016 20:12 # +2

             Фатальный недостаток же.

             Ответить

           • kipar 20.05.2016 09:36 # +2

             Во-первых потому что после этого придется заставить всех пользователей языка Х иметь у себя язык Y(от которого взяли менеджер), и понимать сообщения об ошибках языка Y. Ну и зависеть от поддержки языком Y всяких распбери и других платформ.
             Во-вторых да, сообщество языка X считает язык Y говном по определению, и потому хорошего менеджера на этом языке просто не может быть. Даже если не всё сообщество, даже если 1% - не стоит этот менеджер 1% настоящих фанатов.
             Ну и в-третьих - "а что у вас в Х даже своего менеджера нет? Настолько язык убогий? Небось асинхронный IO не осилили?"

             Ответить

             • 1024-- 20.05.2016 10:49 # 0

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

               Ответить

               • dxd 20.05.2016 12:44 # 0

                 Да нет, термоядерная война решает.

                 Ответить

           • 3_14dar 20.05.2016 13:59 # 0

             Допиливать легче, да и фатальный недостаток.

             Ответить

       • scph77008 19.05.2016 12:34 # 0

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

         Ответить

   • roman-kashitsyn 19.05.2016 11:58 # +4

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

     Ответить

     • dxd 19.05.2016 13:36 # +2

       В сиде сейчас в любой момент сломан либо окамл, либо хаскелл, либо перл. Угадайте, почему.

       Ответить

       • roman-kashitsyn 19.05.2016 14:44 # +1

         Вообще говоря, haskell-platform + cabal-install = непрерывная боль даже на стабильной ветке.
         Недаром люди stack придумали.
         
         А opam у меня вообще сам по себе постоянно ломался, и я забил на Ocaml.

         Ответить

         • 3.14159265 19.05.2016 18:51 # +1

           >Недаром люди slackware придумали.

           Ответить

         • 6E3yMHblu_nemyx 22.02.2019 16:42 # 0

           Например, сейчас «Cygwin» распространяется с изначально сломанным «opam». «Opam» приходится качать и компилировать самому. После этого он нормально работает.
           
           Кстати, заметил особенность «opam»: он умеет даунгрейдить пакеты, если у какого-нибудь пакета в требованиях указан верхний порог версии.

           Ответить

       • Dummy00001 19.05.2016 18:28 # +1

         > В сиде сейчас в любой момент сломан либо окамл, либо хаскелл, либо перл. Угадайте, почему.
         
         как если бы что-то новое. у меня как-то раз в сиде апдейты неделю не ставились. мелочи по сравнению с тем как я раз форс сделал, и апт мне пол системы (включая гуи) удалило (но проапдейтило ту пару пакетов которые я хотел....).
         
         ЗЫ
         https://wiki.debian.org/Teams/ReleaseTeam/Transitions
         https://release.debian.org/transitions/ -
         лол. окамл и хаскелл - "Permanent trackers".
         что означает что либо у языков релиз процесс дерьмо, либо дебьяновы мэнтейнеры мудаки. очень часто первое - но изредка и второе.

         Ответить

         • bormand 19.05.2016 18:40 # 0

           > Permanent trackers
           Это типа всегда самый последний коммит и хуй с ними, пусть сами разбираются? Или что-то другое?

           Ответить

           • Dummy00001 19.05.2016 18:47 # +1

             > > Permanent trackers
             
             > Это типа всегда самый последний коммит? Или что-то другое?
             
             Нет, это означает что почти всегда что-то не работает, потому что где-то что-то надо фиксить или где-то что-то опять в языке поменялось.
             
             Transitions - это когда хотят залить новую версию проги/либи, и в дистре гарантировано что-то сломается (или уже сломалось) с результате аплоада.

             Ответить

             • bormand 19.05.2016 18:48 # 0

               Т.е. во время транзишена они ждут, пока все зависимые проги/либы подтянутся и выпустят новую версию? Ну и попинывают соответствующих разрабов?

               Ответить

               • Dummy00001 19.05.2016 19:02 # 0

                 в общем случае, транизицию начинает мэнтейнер(ы): типа "ща залью, все поломается, и мы это будем чинить". мэнтейнеры не могут знать что/где еще может в ОС сломаться после залива. поэтому заливают новую потенциальную версию в сид, полная ОСь на серваках компилится, и пытаются чинить то что не скомпилилось/не работает.
                 
                 с точки зрения дистра, ответственный это мэнтейнер, и на его решении все и основывается. но если мэнтейнер идиот, то релиз мастеры для критического софта могут просто откатится на старую версию.
                 
                 по какой именно причине окамл и хаскелл на перманентном трэкере - я не знаю.

                 Ответить

                 • bormand 19.05.2016 19:05 # +1

                   > полная ОСь на серваках компилится
                   И прилетает всем юзерам сида?

                   Ответить

                   • Dummy00001 19.05.2016 20:54 # 0

                     сначала сваливается в experimental. sid это unstable, слудующая фаза. если вышло из experimental - это значит что компилируется. а как оно на самом деле работает проверяется в sid (unstable).

                     Ответить

                     • dxd 19.05.2016 21:14 # 0

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

                       Ответить

             • 3.14159265 19.05.2016 18:48 # +3

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

               Ответить

               • bormand 19.05.2016 18:50 # +1

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

                 Ответить

                 • 3.14159265 19.05.2016 18:52 # +5

                   экскриментальный язык.
                   он и так нахуй никому не нужен (кроме выебщиков).

                   Ответить

                   • CHayT 19.05.2016 18:56 # +4

                     сейчас кто-то штангой получит...

                     Ответить

                     • j123123 10.07.2016 03:49 # +2

                       > сейчас кто-то штангой получит...
                       http://bitcheese.net/art_thou/images/full/real_world/haskell-coder.png

                       Ответить

                   • tau 20.05.2016 01:53 # 0

                     https://obsidian.systems/ скажи это им

                     Ответить

                   • roman-kashitsyn 20.05.2016 15:27 # 0

                     > экскриментальный язык.
                     > он и так нахуй никому не нужен
                     
                     Мозилле такой нужен

                     Ответить

                     • 3.14159265 20.05.2016 16:49 # 0

                       >Мозилле такой нужен
                       Ага, и потому они придумали свою питушню (раст).

                       Ответить

                       • CHayT 20.05.2016 22:52 # +2

                         да уж
                         раст -- это как борщ из железного питуха

                         Ответить

                     • guesto 11.07.2016 01:51 # 0

                       Мозилла не нужна

                       Ответить

               • MAMOHT 03.12.2018 06:07 # 0

                 >> Не то что заедушные жабисты с своим занудным backward compability и вечным говном мамонта.
                 
                 Ну хоть что-то у меня вечное.

                 Ответить

   • 3.14159265 19.05.2016 14:06 # +1

     Годный пост.
     gaven забыл. и composter

     Ответить

   • Her 19.05.2016 14:31 # 0

     это вы еще к mysql с питона на 64 битной винде не конектились

     Ответить

   • Her 19.05.2016 14:34 # 0

     там еще?
     gem, bower

     Ответить

   • Zuzik 19.05.2016 15:44 # 0

     Причины того что сущестовование одного, единого пакетного менеджера для языков, дистрибутивов линукса, собственно говоря одного дистрибутива линукса - это требует совместных усилий очень большого количества людей, многодневной работы, мнодневных обсуждений между совершенно разными людьми.
     Плюс к этому - свой пакетный менеджер/дистрибутив линукса - очень большой плюс к ЧСВ. Да и согласитесь - что более красиво "Я один из 20 разработчиков ..." или "Я один из 300 разрабтчиков ...". Если ты в числе 20 человек - больше шанс, что тебя заметят, конечно, если заметят, ту никому не нужную херню, которую ты разрабатываешь.
     Как то так.
     Обобщим это высказываение до различных программ одного назначения. Согласитесь, нередко зоопарк различных файловых менеджеров, текстовых редакторов, графических редакторов и прочее, прочее, ппрочее с открытым исходным кодом заставлял задуматься - где же меньше всего багов, что лучше всего работает, что лучше поддерживает существующие стандарты, либо вообще их поддерживает. И опять же сталкиваемся с проблеммой - слишком много людей, желающих поднять свое ЧСВ. Попытки стандартизации, создать что либо единое - еще один обитатель зоопарка занял свою нишу, либо умер так и не родившись.
     Все печально, выхода из ситуации не видно...

     Ответить

     • Dummy00001 19.05.2016 18:42 # +1

       "это требует совместных усилий очень большого количества людей, многодневной работы, мнодневных обсуждений между совершенно разными людьми."
       
       ты перепрыгнул самое главное препятствие: признанаться что кто-то другой что-то лучше чем ты сделал. шутка.
       
       но самая главная проблема что два центральных дистра - RH & Debian - они просто живут по разным релиз циклам.
       
       даже если формат пакетов стандартизируешь, толку будет мало если все пользуются разными версиями пакетов.
       
       Debian & Ubuntu работает только по тому что Ubuntu ориентируется на дебьяновские версии и конфигурации пакетов.
       
       А с RH-based, там никто никогда с друг другом договорится не мог, начиная с RH который имеет привычку в разных вариантах разные версии использовать.
       
       "Все печально, выхода из ситуации не видно..."
       
       У всех (людей, дистро) разные требования. Как только требования начнут стабилизироваться, начнется и унификация.
       
       Но редактора, файл-манагеры и граф-редакторы можешь забыть: проф/энтузиаст софт никогда не будет унифицирован потому что у всех power-user/более есть свои уникальные требования, и если эти требования не выполняются, народ пишет еще одну версию софта.

       Ответить

       • Zuzik 19.05.2016 19:25 # +1

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

         Ответить

     • 3.14159265 19.05.2016 18:55 # +7

       > Попытки стандартизации, создать что либо единое - еще один обитатель зоопарка занял свою нишу
       xkcd и 14 стандартов.

       Ответить

   • 3_14dar 20.05.2016 14:00 # 0

     >Вот например когда я что-то устанавливл через pip, какая-то там херня требует openssl-devel. И узнаю я это только по ошибкам компиляции, ну т.е. там какая-то поебень криптографическая вызывается из питона, оно при установке компилирует через GCC некое говно которое инклудит какое-то .h говно от openssl, но поскольку этого .h нет, оно обламывается на этапе компиляции. Какого хера я про это должен узнавать только на этапе компиляции блядь?
     Сука, такая же хрень с pycurl. Что нужно доустановить, можно узнать только загуглив ошибку, ИЧСХ доустанавливать нужно через ПМ прыщей.

     Ответить

   • 3_14dar 20.05.2016 14:02 # 0

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

     Ответить

   • 3.14159265 20.05.2016 17:01 # 0

     Сamera ::
            Camera ->
              [(String, AnimState, AnimState)] ->
                [(ILKey, Message)] -> ILKey -> Object
     camera cam _ _ iD
       = (arr
        (\ oi ->
           let gi = oiGameInput oi in
             let clippedcam = oiCollision oi in
               let grounded = oiOnLand oi in
                 let msgs = oiMessage oi in
                   (gi, (clippedcam, gi, grounded, msgs, oi)))
        >>>
        (first ptrPos >>>
           arr
             (\ (pPos, (clippedcam, gi, grounded, msgs, oi)) ->
                (gi, (clippedcam, gi, grounded, msgs, oi, pPos))))
          >>>
          (first (movementKS 400) >>>
             arr
               (\ (forwardVel, (clippedcam, gi, grounded, msgs, oi, pPos)) ->
                  (gi, (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos))))
            >>>
            (first (strafeKS 400) >>>
               arr
                 (\ (strafeVel,
                     (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos))
                    ->
                    (gi,
                     (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos,
                      strafeVel))))
              >>>
              (first lbp >>>
                 arr
                   (\ (trigger,
                       (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos, strafeVel))
                      ->
                      (gi,
                       (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos, strafeVel,
                        trigger))))
                >>>
                (first rbp >>>
                   arr
                     (\ (rtrigger,
                         (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos, strafeVel,
                          trigger))
                        ->
                        (gi,
                         (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos, rtrigger,
                          strafeVel, trigger))))
                  >>>

     Ответить

   • 3.14159265 20.05.2016 17:02 # 0

     (first getDt >>>
         arr
           (\ (dt,
               (clippedcam, forwardVel, gi, grounded, msgs, oi, pPos, rtrigger,
                strafeVel, trigger))
              ->
              ((clippedcam, pPos),
               (clippedcam, dt, forwardVel, gi, grounded, msgs, oi, rtrigger,
                strafeVel, trigger))))
        >>>
        (first
           (arr (\ (clippedcam, pPos) -> (pPos, clippedcam)) >>>
              ((iPre cam) <<< (arr setView)))
           >>>
           arr
             (\ (cam1,
                 (clippedcam, dt, forwardVel, gi, grounded, msgs, oi, rtrigger,
                  strafeVel, trigger))
                ->
                ((cam1, dt, forwardVel),
                 (cam1, clippedcam, dt, gi, grounded, msgs, oi, rtrigger, strafeVel,
                  trigger))))
          >>>
          (first
             (arr (\ (cam1, dt, forwardVel) -> (forwardVel * dt, cam1)) >>>
                moves)
             >>>
             arr
               (\ (cam2,
                   (cam1, clippedcam, dt, gi, grounded, msgs, oi, rtrigger, strafeVel,
                    trigger))
                  ->
                  ((cam2, dt, strafeVel),
                   (cam1, clippedcam, gi, grounded, msgs, oi, rtrigger, trigger))))
            >>>
            (first
               (arr (\ (cam2, dt, strafeVel) -> (strafeVel * dt, cam2)) >>>
                  strafes)
               >>>
               arr
                 (\ (cam3,
                     (cam1, clippedcam, gi, grounded, msgs, oi, rtrigger, trigger))
                    ->
                    ((gi, grounded),
                     (cam1, cam3, clippedcam, msgs, oi, rtrigger, trigger))))
              >>>

     Ответить

   • 3.14159265 20.05.2016 17:02 # 0

     (first (arr (\ (gi, grounded) -> (grounded, gi)) >>> fallingp) >>>
     arr
       (\ (yVel, (cam1, cam3, clippedcam, msgs, oi, rtrigger, trigger)) ->
          ((cam3, yVel), (cam1, clippedcam, msgs, oi, rtrigger, trigger))))
     >>>
     ((first (arr dropCam) >>>
        loop
          (arr
             (\ ((cam4, (cam1, clippedcam, msgs, oi, rtrigger, trigger)),
                 msgn)
                ->
                ((msgn, msgs, rtrigger),
                 (cam1, cam4, clippedcam, msgs, oi, rtrigger, trigger)))
             >>>
             (first
                (arr
                   (\ (msgn, msgs, rtrigger) ->
                      case (isEvent rtrigger) of
                          True -> ([], msgn)
                          False -> ((getMsg0 msgs msgn), msgn))
                   >>> ((iPre ([], [])) <<< identity))
                >>>
                arr
                  (\ ((msgn, msgi),
                      (cam1, cam4, clippedcam, msgs, oi, rtrigger, trigger))
                     ->
                     ((cam1, cam4, clippedcam, msgi, msgs, oi, rtrigger,
                       trigger),
                      msgn)))))
       >>>
       arr
         (\ (cam1, cam4, clippedcam, msgi, msgs, oi, rtrigger, trigger) ->
            (oi, (cam1, cam4, clippedcam, msgi, msgs, rtrigger, trigger))))
      >>>
      ((first (arr (\ oi -> oiHit oi) >>> (iPre (noEvent) <<< identity))
          >>>
          loop
            (arr
               (\ ((hitEv,
                    (cam1, cam4, clippedcam, msgi, msgs, rtrigger, trigger)),
                   currentHealth)
                  ->
                  ((currentHealth, hitEv),
                   (cam1, cam4, clippedcam, msgi, msgs, rtrigger, trigger)))
               >>>
               (first
                  (arr
                     (\ (currentHealth, hitEv) ->
                        case (isEvent hitEv) of
                            True -> currentHealth -
                                      (realToFrac
                                         ((length (fromEvent hitEv)) * 3))
                            False -> currentHealth)
                     >>> ((iPre 100) <<< identity))

     Ответить

   • 3.14159265 20.05.2016 17:03 # 0

     >>>
                  arr
                    (\ (currentHealth,
                        (cam1, cam4, clippedcam, msgi, msgs, rtrigger,
                         trigger))
                       ->
                       ((cam1, cam4, clippedcam, currentHealth, msgi, msgs,
                         rtrigger, trigger),
                        currentHealth)))))
         >>>
         arr
           (\ (cam1, cam4, clippedcam, currentHealth, msgi, msgs, rtrigger,
               trigger)
              ->
                  (msgs,
                   (cam1, cam4, clippedcam, currentHealth, msgi, rtrigger,
                    trigger))))
        >>>
        ((first ((iPre noEvent) <<< identity) >>>
            loop
              (arr
                 (\ ((msges,
                      (cam1, cam4, clippedcam, currentHealth, msgi, rtrigger,
                       trigger)),
                     kills)
                    ->
                    ((kills, msges),
                     (cam1, cam4, clippedcam, currentHealth, msges, msgi,
                      rtrigger, trigger)))
                 >>>
                 (first
                    (arr
                       (\ (kills, msges) ->
                          kills + (length (findKills (event2List msges))))
                       >>> ((iPre 0) <<< identity))
                    >>>
                    arr
                      (\ (kills,
                          (cam1, cam4, clippedcam, currentHealth, msges,
                           msgi, rtrigger, trigger))
                         ->
                         ((cam1, cam4, clippedcam, currentHealth, kills,
                           msges, msgi, rtrigger, trigger),
                          kills)))))
           >>>
           arr
             (\ (cam1, cam4, clippedcam, currentHealth, kills, msges, msgi,
                 rtrigger, trigger)
                ->
                ((msgi, rtrigger),
                 (cam1, cam4, clippedcam, currentHealth, kills, msges,
                  trigger))))
          >>>
              (first
                 (arr (\ (msgi, rtrigger) -> (rtrigger, msgi)) >>>
                    ((iPre (noEvent, [])) <<< identity))
           
                >>>

     Ответить

   • 3.14159265 20.05.2016 17:04 # −1

     >>>
         arr
           (\ ((rev, msgi2),
               (cam1, cam4, clippedcam, currentHealth, kills, msges,
                trigger))
              ->
              (clippedcam,
               (cam1, cam4, currentHealth, kills, msges, msgi2, rev,
                trigger))))
        >>>
        (first ((iPre cam) <<< identity) >>>
           arr
             (\ (ccam,
                 (cam1, cam4, currentHealth, kills, msges, msgi2, rev,
                  trigger))
                ->
                ObjOutput{ooSpawnReq =
                            (trigger `tag`
                               [(ray (cpos cam1) (viewPos cam1) iD)]),
                          ooObsObjState =
                            OOSCamera{newCam = cam4, oldCam = cam1,
                                      health = currentHealth, ammo = 100,
                                      score = kills,
                                      cood =
                                        case (isEvent rev) of
                                            True -> reverse $
                                                      map getCoordFromMsg
                                                        (msgi2)
                                            _ -> []},
                          ooKillReq = noEvent,
                          ooSendMessage =
                            case (event2List msges) of
                                [] -> noEvent
                                _ -> (Event ()) `tag`
                                       (case
                                          (findEnemies
                                             (event2List msges))
                                          of
                                            [] -> []
                                            _ -> [toTargetPosition iD
                                                    (cpos ccam)
                                                    (head
                                                       (findEnemies
                                                          (event2List
                                                             msges)))])})))

     Ответить

     • 3.14159265 20.05.2016 17:05 # +3

       Хаскель это чистый и понятный код.

       Ответить

       • inkanus-gray 20.05.2016 17:42 # +5

         Программист на Лиспе даже на Хаскеле пишет, как на Лиспе.

         Ответить

       • CHayT 20.05.2016 19:45 # 0

         ты нахуя нахуя proc-то рассахарил?

         Ответить

         • 3.14159265 20.05.2016 19:56 # +2

           Код не мой, я просто разместил гавнидло.

           Ответить

           • inkanus-gray 20.05.2016 22:14 # +6

             «Дорогие дедушка и бабушка! Мне очень стыдно и я хочу попросить у вас прощения. Когда я был у вас на каникулах, я тайком съел банку варенья, а потом в неё накакал.»
             — Говорил я тебе, дура старая, что в банке говно, а ты: «Засахарилось! Засахарилось!»

             Ответить

       • bormand 20.05.2016 22:18 # +4

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

         Ответить

         • 3.14159265 20.05.2016 22:25 # +5

           >Кстати, можно же ворьировать проги на лишпе.
           я такую шнягу для J сделал. но кегдан больше не форсит, потому испытывать не на ком.

           Ответить

           • bormand 20.05.2016 22:39 # 0

             Ну vxwxv то здесь.

             Ответить

             • inkanus-gray 20.05.2016 22:51 # 0

               Ещё Abbath заглядывал.

               Ответить

               • bormand 20.05.2016 22:58 # +2

                 Ну вот, уже джва потенциальных клиента.

                 Ответить

                 • inkanus-gray 20.05.2016 22:59 # +3

                   Но Abbath здесь бывает ОЧЕНЬ нерегулярно. Никто не знает времени его следующего явления народу.

                   Ответить

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

   Ошибка компиляции комментария:

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

   Где здесь C++, guest?!

   А не использовать ли нам bbcode?

   • [b]жирный[/b] — жирный
   • [i]курсив[/i] — курсив
   • [u]подчеркнутый[/u] — подчеркнутый
   • [s]перечеркнутый[/s] — перечеркнутый
   • [blink]мигающий[/blink] — мигающий
   • [color=red]цвет[/color] — цвет (подробнее)
   • [size=20]размер[/size] — размер (подробнее)
   • [code=<language>]some code[/code] (подробнее)

   Проверочный код: *