- 1
(lambda x:request.profile.role if request.profile.role!=5 else 4)(request.profile.role)-
Python / Говнокод #12270
−100
Запостил:
хуита,
11 Декабря 2012
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Правда, совершенно неясно чего автор хотел этим добиться...
Это даже не говнокод, это говномысль.
сдается, мне аффтар экономил символы, и хотел написать
но на полпути забыл что делал.
> бля меня заебало
Ты зашкварен некоторыми недоязыками программирования. Это постфиксный естественный if. Вот если бы ты не имел эту дурную привычку и знал бы English на уровне носителя языка, то у тебя бы не было проблем с чтением этого кода.
Переходите на правильную сторону силы! У нас есть макросы!
Можно подумать, Python не нормальный язык. Более чем. Сложно найти язык настолько простой и удобный, как python. Есть пара неприятных артифактов вроде постфиксного if, но это не критично. И метапрограммирование там совсем несложно пилить.
А от запиливания своих синтаксисов в большинстве случаев больше вреда, чем пользы.
P.S. Там даже Method Resolution Order начиная с версии 2.3 слизан из почитаемого самим @wvxvw Dylan, т.е. работает через линеаризацию
Хотя, язык с динамической типизацией по определению... кхгм... да, теперь я назвал его ненормальным.
Мне самому приходится использовать Питон, вынужденно, ибо легаси-проект на Си напичкан кучей скриптов на разных языках (в том числе Питон). Сделано это именно из-за потребности чего-то наподобие МП.
Покажи мне язык со статической типизацией, метапрограммированием, с привычным синтаксисом и семантикой, и с богатым фреймворком.
> А от запиливания своих синтаксисов в большинстве случаев больше вреда, чем пользы.
Угу, программируя на Бейсике без определения своих функций, тоже можно сказать, что достаточно goto. Ведь если Вася введёт свои функции, то Петя в них запутается!
Синтаксис, выражающий предметную область - великое благо, ибо позволяет программеру и заказчику говорить на одном языке. Конечно, при том условии, что это поддерживается самим языком и IDE (с автодополнением, подсказками, рефакторингом и т. п), а не текстовым препроцессором.
В общем, не вижу смысла обсуждать вкус устриц с тем, кто их не пробовал.
В Scala пытаются сделать МП. Вон уже запилили reify. Когда (если) в Скале сделают нормальное МП, и ты его вкусишь, жду твоих хвалебных постов ;)
Другой вариант применения: часто знать наперед типы импортируемые из другого модуля невозможно, т.как, например, другого модуля еще не существует, и программа должна "на ходу" принимать решения о возможности, или невозможности применения функции к данным какого-то типа.
Кроме того, иногда лучше отложить определение стратегии приведения типа и вызова функций которые с ним работают до рантайма, потому что только там будет по-настоящему известно как именно это лучше сделать.
Просто когда вся без исключения типизация динамическая, тогда плохо, т.как компилятор не может принять хорошие решения об оптимизации, т.как очень мало известно о том, что именно нужно делать.
На каком-то из коммитетов oopsla, которые предшествовали появлению ES4 был такой доклад типа "Well-typed program can't be blamed", где говорилось про систему с опт-ин типизацией. (ОК, как бы понятно, откуда идея пришла). Ну и с того времени в языках, которые с того момента разрабатываются так или иначе пытаются это воплотить. HaXe, Dart. Ну, а в языках со статической типизацией, где это не возможно, там пытаются это как-то сделать через то, чтобы хотя-бы часть типов компилятор выводил сам (типа того же var в C#).
Скорее, Nemerle заставляет людей читать не то, что реально написано, подозревая всех окружающих в глупости.
Я обеими руками за строгую типизацию, а выбор статическая/динамическая часто зависит от задачи. Например, я считаю, что динамическая типизация лучше сочетается с вебом, чем статическая (ближе по духу, чтоли, хоть это и спорный вопрос).
Подход "сделать класс Number и делать свитчи по типу в операторах" фактически приводит нас к динамически типизированной системе, реализованной на статически-типизированном языке.
А хренли, в кишках этой питузации то же самое и делается.
Где статическая типизация - ну, в примере с массивами очень дорого обойдется. (2^32 типов массивов? :))
Ну, вспоминая твои знания о вариантных полях в одной из соседних тем, я не буду тебе рассказывать про наследование и прочее, ладно?
class Array30 : public Array29 {
int item29;
}
class Array31 : public Array30 {
int item30;
}
...
Больший массив можно будет передать в функцию, которая требует меньший, а наоборот - нет. Удобно же.
Ах да, и статическая проверка границ массива! Ты просто не сможешь получить item, которого в массиве нет.
А чтобы обойти этот массив, опытный ООПизд вместо цикла воспользуется паттерном visitor, реализованным примерно так:
Пора уже ввести ключевое слово, которое говорит о том, как я хочу раскрыть шаблон - при компиляции, нагенерив тонны бесполезной копипасты, или при выполнении, то есть передавая кучу указателей на функции и кучу переменных.
Ну и разрешить наконец шаблоны от переменных.
переменных.
Пиздец-пиздец. Ты же первый побежишь кричать "петушиные крестошаблоны" и "смотрите всё какое говно я на них написал".
>ввести ключевое слово, которое говорит о том, как я хочу раскрыть шаблон
А вот это полезно. Что-то типа inline. Можно даже для унификации так и назвать.
Да, но это же не значит, что шаблоны от переменных не нужны.
Добавим в язык - будет говно, но это совсем не означает что оно там не нужно.
генерики на крестах, без каких бы то ни было предположений о свойствах типа, как копируемость, его возможные и невозможные методы - будут приводиться к использованию void * + size_t, т.е. всё то, что и так было и есть в сишкоблядских bsearch или qsort
виртуальной машины, которая сама всё знает про каждый объект, тут нет
необходимы дополнительные контракты на передачу аргументов для какой-никакой типобезопасности, но это будет серьезная переделка языка, и ради чего?
чтобы мигрирующие крестоненавистники чувствовали себя удобно после своих мёртвых языков, типа ады, где даже сраный метод нельзя вызвать у объекта, передаваемого как "шаблонный" аргумент
Лолшто
Уже есть. Явное инстанцирование называется.
Ещё глянь на Loki::GenScatterHierarchy и Loki::GenLinearHierarchy
для управляемости результатом генерирования.
А также boost::mpl, в частности какой-нибудь BOOST_PP_REPEAT
Отдельные примеры с динамикой действительно короче чем со статикой. Но дальнейшая их поддержка намного сложнее.
Лол, я два года назад открыл для себя лисповые макросы, по сравнению с которыми ваш Nemerle не представляет из себя ничего особо выдающегося.
> жду твоих хвалебных постов
Меня просто забавляет, когда люди начинают петь про очередные серебрянные пули и неимоверную красоту. Я лично уже на собственной шкуре ощутил, что основна проблема при разработке реальных систем не в поддержке каких-то фишечек со стороны языка, а в сложности самой предметной области.
Макросы для DSL - это прекрасно, я ничего не имею против. Но, как и любая достаточно мощная и сложная технология, они имеют недостатков не меньше, чем преимуществ, и использоваться должны только тогда, когда более простые концепции совсем не подходят.
Сэр, не передёргивайте! Я разве говорил, что макросы в N - что-то выдающееся?
Огромное преимущество Немерла - статическая типизация вкупе с макросами.
Да, в Лисп/Схему тоже можно добавить статику. Но синтаксис становится намного сложнее, и поэтому игра не стоит свеч.
>Меня просто забавляет, когда люди начинают петь про очередные серебрянные пули и неимоверную красоту.
Полностью согласен. Серебряных пуль пока нет. Немерл - небольшой шажок на пути к светлому будущему.
(кто там выше пел про красоту Путхона?..)
Синтаксис практически не меняется, добавляется пара s-выражений с хинтами типов . В языках Lisp-семейства синтаксис вообще очень прост.
> кто там выше пел про красоту Путхона
Про красоту не было ни слова, только про простоту и удобство. Метапрограммирование там нужно настолько редко, что лучше 10 раз подумать прежде, чем его использовать. В голову навскидку проиходит только 2 сценария использования - реализация сетевых протоколов и ORM.
Только вот самые главные плюсы статической типизации это не добавляет, тк ошибки типов все равно обнаруживаются во время выполнения, а не компиляции. Ну и качество оптимизации должного уровня при этом не достижимо.
>то основна проблема при разработке реальных систем не в поддержке каких-то фишечек со стороны языка, а в сложности самой предметной области.
Люто плюсую вас, сер. Упоротые сектанты и просто мудаки и вроде гумна орущие "мой хацкиль круче твоих крестов" и "какой язык лучше" не пройдут.
Хотя пхп конечно реальный кал.
http://dpaste.org/2Yd6j/ вот тут пример
Вот x в выражении действительно был лишним.