LINUX.ORG.RU

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

То есть например набрать в гугеле запрос

python HPC

выше Ваших возможностей? Ой да, Вы же не знаете что такое HPC - это же чисто русская фишка которой занимается «один сантехник и один неудавшийся физик», не правда ли?

Я Вам искренне сочувствую, пытаться работать в CS c Вашими способностями к восприятию и анализу информации это беспримерный подвиг! Подобные трудности преодолевал Мересьев выползая к своим зимой две недели со сломанными ногами, а у Вас вся жизнь такая…

AntonI ★★★★
()
Ответ на: комментарий от I-Love-Microsoft

только с табами

Расстрелять.

ox55ff ★★★★★
()
Ответ на: комментарий от no-such-file

В общем, да. Только PHP почему-то привлекает одних рукожопов. Тут в одной соседней теме прорекламировали очередной «новый» форум на PHP, который написан так же рукожопно, как и 100% всех остальных форумов на PHP, но при этом авторы еще шипят и плюются, и не понимают, что же в этом рукожопного. Рукалицо.

emorozov
()
Последнее исправление: emorozov (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Не знаю, фанатики питона пока что ссыкливо игнорируют этот вопрос.

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

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

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

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

skiminok1986 ★★★★★
()
Ответ на: комментарий от no-such-file

Это подходит к любому распространенному ЯП, и не только к ЯП.

У любого ЯП есть недостатки, но раз им пользуются - значит достоинства перевешивают недостатки. Это инженерия, любое инженерное решение это компромисс.

А вот граждане кричащие от ненависти к ЯП скорее всего пытаются оправдать недостатками ЯП свою рукожопость. Это уже психология. Если чувак вроде @untitl3d забивая гвоздь попал молотком по пальцу, то виноваты разумеется молоток, гвоздь и бетонная стена в которую этот гвоздь никак не хотел входить.

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

AntonI ★★★★
()
Ответ на: комментарий от no-such-file

Не знаю, фанатики питона пока что ссыкливо игнорируют этот вопрос.

Не игнорируем, просто бессмысленно отвечать на какие-то «подколки» от людей, которые никогда не писали на Python и не могут понять, что никакой проблемы в этом нет.

Это вообще, по сравнению с любой другой проблемой Python (например, сложной и запутанной экосистемой различных вариантов организации virtualenv), даже не проблема. С первым в той или иной ипостаси сталкивается любой разработчик на Python. Со второй - никто и никогда не испытывал проблем. Она только в голове у тех, кто прочитал ровно один абзац из туториала по Python, и сразу же побежал всюду кричать: «Я такой умный, а ваш Python говно! В нём отступы как в Фортране и копировать код по Ctrl-C/Ctrl-V невозможно!»

Хотя на самом деле, отступы радикально отличаются от того, как надо форматировать код в Фортран (но неучи же не знают ни Питон, ни Фортран), и проблем с копированием/редактированием тоже никогда не вызывают.

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

Вот многопоток это проблема.

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

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

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

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

Именно. Руками. Каждый раз. Если речь про какую-нибудь лабораторку или посчитать статистику в Юпитере, в общем то, что один раз сделал, сдал и забыл, то проблем нет. Если тебе нужно поддерживать код годами, рефакторить и т.д., то этот дроч надоедает. Я хочу думать о решаемой проблеме, а не считать до четырёх 100500 раз в день.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я уже давно перестал критиковать PHP как язык. Потому что как язык он был полным говном в первых версиях. Просто где-то на PHP 4 перестал с ним работать и не слежу, что там выходило позже.

Возможно, нонешний PHP отличается от PHP тех времён, как земля и небо. Мне даже неинтересно смотреть. А повторять критику тех старых версий PHP уже неправильно, т.к. возможно эти родовые недостатки удалось преодолеть, хотя сомневаюсь. Но ни капли мотивации лезть проверять нет.

Просто PHP калечит мозг. Все проекты на PHP, в код которых я залезал, были написаны отвратительно. Спагетти-код, архитектура Big Ball of Mud, постоянные изобретения велосипедов с квадратными колёсами. Особенные лулзы, это «статьи» писателей на PHP, когда они с горящими глазами описывают, как «открыли» какой-то подход к разработке или какой-то паттерн, который во всех других языках начали использовать 10-15 лет назад. Да ещё и этот паттерн реализуют криво и неправильно.

Казалось бы, причём здесь язык? Не знаю, но PHP прямо вот перекрывает каналы поступления информации в мозг. Если человек, на него подсел, то игнорируя вообще всё, что происходит в мире IT, будет уже всю жизнь хреначить гроздья спагетти из инклудов, дырявые, нечитаемые, и неподдерживаемые.

Это субъективно, да, но исключений ещё не видел.

emorozov
()
Ответ на: комментарий от no-such-file

Эммм… я КАЖДЫЙ день в течении 20ти лет пишу 1-3 питоньих программки и еще развиваю/поддерживаю питонью кодовую базу в пределах 10 тыщ строк (немного, но у нас вообще проекты маленькие). За все это время я РОВНО ТРИ РАЗА сталкивался с проблемой некорректных отступов при работе с чужим кодом, и НИ РАЗУ не считал до четырех.

ЧЯНТД?

AntonI ★★★★
()
Ответ на: комментарий от no-such-file

Ты вот прям расписался в том, что ни разу не писал код на питоне и не редактировал. Потому что никто не считал и не считает пробелы. Вот не требуется это.

Это только иллюзия в голове тех, кто прочитал про отступы, но сам при этом ни разу ничего не писал на python.

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

Хотя на самом деле, отступы радикально отличаются от того, как надо форматировать код в Фортран

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

Это вообще, по сравнению с любой другой проблемой Python (например, сложной и запутанной экосистемой различных вариантов организации virtualenv), даже не проблема

Это проблема. Но я согласен, что по сравнению с остальным говном в питоне это ещё цветочки.

никто и никогда не испытывал проблем

ЛОЛ ну это просто эпичное 4.2. Каждая вторая проблема у начинающих это кривое выравнивание. Я понимаю, человек ко всему может привыкнуть, но не надо рассказывать что «это норма».

no-such-file ★★★★★
()

Охохо как у питономакак пердаки полыхают от банальных фактов, один даже в психолухи записался и аналоговнетную оправдывает. Это 5 ящитаю.

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

функциональщина же, в популярной интерпретации. в принципе этот тренд в моде оформился уже несколько десятилетий назад и с тех пор не менялся

Где же весь этот функциональный код? Все пишут на Scala, Haskell, Clojure?

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

emorozov
()
Ответ на: комментарий от no-such-file

Каждая вторая проблема у начинающих это кривое выравнивание.

Нет. Я в т.ч. преподаю питон 15 лет, в т.ч. начинающим - нет, это НЕ ЯВЛЯЕТСЯ ПРОБЛЕМОЙ у начинающих. Не надо фантазировать.

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

Ты вот прям расписался в том, что ни разу не писал код на питоне и не редактировал. Потому что никто не считал и не считает пробелы. Вот не требуется это

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

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от AntonI

Зачем ты пытаешься ему что-то доказать? С такими травмами некоторых комментаторов уже нужны специалисты другого профиля.

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

Наверное я наивен и до сих пор верю в людей?;-)

AntonI ★★★★
()
Ответ на: комментарий от no-such-file

Не верю. Потому что я львиную долю своей жизни пишу на Python. Поэтому работал в куче организаций, где все пишут на Python. Читаю статьи, форумы, ньюсгруппы и блоги о Python. Я даже преподавал и преподаю Python.

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

В мире обсуждений Python часто обсуждают баттхёрт, скажем, от пакаджей и модулей. Или от GIL. Но никто никогда не обсуждает отступы, потому что это не проблема.

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

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

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

Внутри питона это конечно не обсуждают. Что тут обсуждать? Это данность и её никак не изменить. Все страдают и ты страдай. Молча.

no-such-file ★★★★★
()
Ответ на: комментарий от emorozov

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

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

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

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

Ох, ну хоть у каких-то питонистов есть зачатки разума и критического мышления.

Само появление таких функций говорит о том что код не айс

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

Как учебный язык питон годится, спору нет. Годится для скриптов в jupyter. Но писать на нём что-то долгоиграющее это боль. Код скатывается в говно, которое очень сложно и муторно потом ворочать.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

В этом смысле ИМНО проблемы типизации в толстых проектах куда актуальнее проблем выравнивания.

Вообще Вы первый человек который мне жалуется на проблемы с выравниванием;-)

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

Тормозной - несколько лет назад я переписал свои скрипты с баша на питон, и они стали работать медленнее, лол. Пусть и ненамного.

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

Динамическая типизация, из-за которой масса времени уходит на пердолинг с домыслами интерпретатора. Легче сразу указать транслятору ху из ху.

Согласен с тем, что динамическая типизация зло. Однако должен заметить, что последних версиях появилась возможноть аннотировать переменные и функции. И эти аннотации так же понимает IDE. Что значительно упрощяет процесс написания кода(при условии, что ты свои же аннотации не нарушаешь)

Питоновский ООП мне в своё время чердак на нуль поделил, из-за чего я стал ненавидеть ООП. В С++ оно как-то понятнее.

Дай угадаю, C++ твой первый ОО язык?

Aswed ★★★★★
()

позиционируется как простой/эффективный язык и платформа, на деле наоборот представляет собой источник постоянного гемора на всех этапах:

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

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

  3. В эксплуатации: интерпретируемая природа языка порождает большое количество ошибок отлавливаемых только уже конечными пользователями. Поскольку нет поддержки интерфейсов разрабатывать что-то сложнее 300 строчек кода весьма проблемно.

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

С долгоиграющим как раз проблем нет, проблемы с толстыми проектами

Я имею в виду долгих по времени. Постепенно проект обрастает мясом, если это не какая-то узкоспециальная вещь.

первый человек который мне жалуется на проблемы с выравниванием

Так я ж говорю, внутри сообщества это бесполезно. Ну вот вы рассказываете ученикам, что надо выравнивать так и так. И что они должны вам возразить? Максимум что они могут сказать, это что «а вот там скобки». А вы им в ответ, что там скобки,а тут так. Ну и всё дискуссия окончена. Жри что дают или ищи другой язык/курс.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Так я ж говорю, внутри сообщества это бесполезно.

Еще раз, как вне так и внутри сообщества обсуждаются вещи которые беспокоят. Скажем динамическая типизация обсуждается - дообсуждались до аннотирования типов. Изменяемые/неизменяемые типы обсуждаются - пишутся годные статьи которые раскрывают подводные камни. Ни от динамической типизации, ни от бардака с изменяемыми/неизменяемыми типами никуда не деться, но об этом таки говорят и отрабатывают методики решения проблем.

Но вот о форматировании не говорят и методики решения проблем не отрабатывают - потому что такие проблемы возникают крайне редко. У Вас вот у первого.

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

Нет, тут ещё один пациент есть, которому никак не даются отступы. Заодно ещё какие-то рассуждения о «проблемах», которых либо нет (интерфейсы уже есть официально из коробки, до официальных были неофициальные), либо без конкретики («python проект нельзя развернуть»).

У меня вот множество раз не получалось развернуть проекты на C, C++, Java. Но я не называю их поэтому гомном. Хотя Java называю, не буду врать. ) Не люблю жабью монструозность, проявляющуюся как в невероятной многословности кода (аж в глазах начинает рябить), так и в том, что любая утилита на жабе, тащит в систему гигабайты мусорных зависимостей, и каждый запуск занимает ощутимое время. Даже, блин, долбаный plantuml, поэтому собираюсь найти ему замену на Python или Go, только лишь переписывать тонны puml диаграмм некогда.

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

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

Но пишут и достаточно много. Не даром же на каждый чих пихают django и gunicorn. Хотя, я скорее соглашусь, что это просто использование пайтона не там, где его стоит использовать.

skiminok1986 ★★★★★
()
Ответ на: комментарий от no-such-file

Я хочу думать о решаемой проблеме, а не считать до четырёх 100500 раз в день.

Тут до четырёх считает редактор, а не ты. Это как скобочки в лиспах – если у тебя блокнот вместо редактора, то тебе тяжело. Если у тебя приспособленный к облегчению написания кода редактор, то проблемы как бы и нет.

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

Но вот о форматировании не говорят и методики решения проблем не отрабатывают

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

И методики её решения отрабатывают, начиная с PIP и заканчивая советами использовать правильные IDE.

Если загуглить «IndentationError: unexpected indent» то можно увидеть, что есть и вопросы и обсуждения.

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

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

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

Пока Вы страдаете над отступами другие решают на питоне интересные, актуальные задачи и делают это с большим удовольствием - хотя могли бы взять луа/руби/лисп или даже хаскель;-)

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

По форматированию все уже отработано лет 15 назад.

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

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

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

Насчет монструозности обычно она ощущалась на сравнении супернавороченных энтерпрайз продуктов, где возможности такие каких до сих пор нигде нет и возможно не будет и скриптовых хеловорлдов на локалхосте. Сейчас некоторые хеловорлды на «простых» языках программирования порзавились и стали монструозны ничуть не менее при том, что по качеству они остались харкодом и говнокодом. Например гитлаб отжирающий не менее 4га оперативки. В тоже время, одна среда разработки для IoTа на джаве у меня кушала мегабайтов 20 оперативки. С появлением грааля, т.е. компиляции в бинарники приложения на джаве могут жрать сопоставимо с любыми другими платформами, например для веб-сервиса это от 20и до 200-300мб.

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

все уже отработано лет 15 назад

А вопросы на SO продолжают поступать.

no-such-file ★★★★★
()
Ответ на: комментарий от AntonI

собеседники не будут над Вами глумиться

Пока что происходит строго наоборот. Кстати, о любителях питона. Это всё сплошь либо непрограммисты, которые любят питон за то, что в нём можно делать по шпаргалке: чтобы посчитать это, пиши так, чтобы сделать то, пиши это. Либо люди с таким же квадратно-гнездовым мышлением, как и сам питон, без фантазии и с замашками прапорщика. Сотрудники замшелых НИИ, госшаражек, банков и силовых структур. Вот взять хотя бы вас, на пару с @emorozov. Даже ники вы себе выбрали максимально тупо и прямолинейно: имя фамилия. Звание ещё забыли добавить, по штатному расписанию. У вас же есть звание, товарищ?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Даже ники вы себе выбрали максимально тупо и прямолинейно: имя фамилия

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

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

В вашем классе, небось, за такое в лошары определяют?

В остолопы.

Вангую, у них даже волосы не покрашены и пирсинга нет

Вместо этого есть лампасы.

no-such-file ★★★★★
()
Ответ на: комментарий от skiminok1986

наблюдение конечно же, типичный код на питоне это перекладывание данных из одной хештаблички в другую. Вот сейчас попробовал просто навскидку ввести в поиске гитхапа python открыть какой-нибудь код и найти там хоть один паттерн и перебрав десяток файлов ни одного не увидел - везде тупо присваивания с циклами и условиями в линеечку и вызовы методов, которые делают тоже самое. Никаких архитектурных решений в таком типичном питон коде просто нет. Ах да, однажды, один раз за 20 лет, я где-то видел pub-sub, но это был, пожалуй единственный случай.

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

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

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

Чувак, может быть, ты просто искал ключевые слова, как жабье EnterpriseJavaObjectFactoryFactoryFactory?

Например, в том же Django используется несколько паттернов, но при этом они не называются явно по названию соответствующего паттерна из GoF.

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

emorozov
()
Ответ на: комментарий от no-such-file

Пока что происходит строго наоборот.

До-до. Это примерно как с отступами, Вы третью страницу кричите что это основная проблема питона, а питонисты этой проблемы оказывается дружно не замечают. Тогда Вы приводите убойный аргумент - ссылку на SO (вопрос про отступы там где то между «почему у меня сегфолт» и «как открыть файл») и кажетесь себе ужжжжасно убедительным, а остальные смотрят на Вас с глубоким недоумением и вежлив молчат.

Кстати, о любителях питона. Это всё сплошь … люди с таким же квадратно-гнездовым мышлением, как и сам питон, без фантазии и с замашками прапорщика.

У Вас вангователь сломался окончательно. Загуглить «python HPC» Вы даже на пару с @untitl3d не в состоянии? Открою Вам военную тайну - современные физика и прикладная математика требуют фантазии и абстрактного мышления в куда больших объемах чем программирование.

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

Всего хорошего.

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

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

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

Syncro ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)