- 1
https://habr.com/post/417047/-
Куча / Говнокод #24488
−1
Гвидо уходит напитон из питона
Запостил:
guestinxo,
13 Июля 2018
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Если уж при Гвидо туда пропихнули хуиту (:=), то без него, думаю, преврятят Питонию в какой-нибудь Перл или Руби.
зы: руби охуенен, братан
не кроши на него батон
да и перл не так уж плох для своего времяни и области применення
Да и Perl не так уж плох для любого времени и любой области примнения.
// fixed
я писал комментарий, а он удалялился
ох, пхп
так вот: Perl был создан чтобы легко и просто парсить текстовые файлы и крутить их как нужно. И чтобы делать это в небольших скриптах. Он для этого идеален.
А когда на нем пишут сложную бизнес-логику с кучей классов и кучей файлов то он превращается в ад. И он не виноват: он НЕ для этого.
Practical extranction and report language.
Благодаря своему происхождению Perl был богатым языком даже тогда, когда служил «просто» языком преобразования данных, предназначенным для перемещения по файлам, просмотра больших объемов текста, создания и получения динамических данных и вывода легко форматируемых отчетов, основанных на этих данных. Но в какой-то момент начался расцвет Perl. Он стал также и языком для работы с файловой системой, управления процессами, администрирования баз данных, программирования в архитектуре клиент-сервер, создания безопасных программ, управления данными в Сети и даже для объектно-ориентированного и функционального программирования. Эти возможности не были просто механически присоединены к Perl — каждая новая синергически работает с остальными, поскольку с самого начала Perl проектировался как интегрирующий язык.
<...>
Хотя Perl особенно популярен среди системных программистов и разработчиков для Интернета, это связано лишь с тем, что они первыми его открыли; аудитория Perl значительно шире. Получивший при создании скромный статус языка обработки текста, Perl превратился в сложный язык программирования общего назначения с богатой средой разработки программ, укомплектованной отладчиками, профайлерами, формировщиками перекрестных ссылок, компиляторами, библиотеками, синтаксически ориентированными редакторами и всеми остальными атрибутами «настоящего» языка программирования — если они вам требуются. Но все они относятся к поддержке возможностей решения сложных задач, с чем справляются многие другие языки. Уникальность Perl в том, что он никогда не терял из виду возможность легко решать задачи простые.
В том-то и проблема.
ЯПу лучше бы сразу же проектироваться и использоваться так, как спроектировался. Дикорастущий сад приводит к хаосу.
Перл хороший, но
1) в нем дохуя операторов, некоторые лучше бы было реализовать функциями (https://perldoc.perl.org/perlop.html)
2) мне не нравится что все функции varargs по умолчанию. Это почти никогда не надо. Хак с хешем, превращающмимся в named parameters тоже не очень (от перла эта болезнь передалась в Ruby)
3) доллар не нужен. Это мусор семантический, чтобы не выглядеть чужаком в шелпрограмминге
4) blessed, new и стрелочка мало того что тоже мусор, так еще и мозговзрыв. Вы или не умейте ООП вообще (как си) или умейте его в нормальных терминах.
5) -s и use strict надо быть по умолчанию
6) один факт наличия "use English;" много говорит о языке
В целом же Perl крут, имеет кучу отличных модулей на CPAN, и маленькое, но сильное сообщество.
Если ты берешь программиста на Perl на работу то он почти никогда не мудак-скрипткидди (а, например, с питонистом такое может случиться)
Если С++снику платят больше, чем PHPшнику то это не потому что С++ сложнее, а потому что сложнее задача, и ее может решить только более крутой программист, ну а язык это просто инструмент.
С остальным, в принципе, согласен.
Вот это сомнительно. А если вдруг наоборот пхп-шнику платят больше? Что это значит, что у него задача сложнее или он более крутой программист? Я думаю, это значит, что какой-то из бизнесов просто приносит больше денег или что-то в этом роде.
Видишь, педоматик какой-то использует
используют люди, да
рубийное соощество, кстати, очень много сделало для
1) DSLей
2) веб-фреймворков
3) configuration as code
4) BDD
Зато PHP сообщество изобрело правку .php файлов на продакшене через тотал коммандер по ftp
- "ой, мы сделали непонятную херню, а давайте её присобачим всюду, куда дотянутся наши потные ручки"
Без словестного описания фич их невозможно ни тестировать, но синхронизировать свое понимание с бизнес-оунером (см "Specification by Example" Аджича)
>>но сам язык, похоже, не нужен
толи дело пхп, да?
Хахаха. Они даже FAQ не удосужились поправить
https://docs.python.org/3.8/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression
Why can’t I use an assignment in an expression?
Many people used to C or Perl complain that they want to use this C idiom:
The reason for not allowing assignment in Python expressions is a common, hard-to-find bug in those other languages, caused by this construct:
во всем остальном необходимость есть
Ну не знаю, я уже джвадцать джва года жду, когда всё это недотипизированное скриптоговно уже сдохнет.
Хотя я, пожалуй, соглашусь что в 1993 году смысла в скриптовых языках было куда больше чем сейчас
Мне 90% того что пишется на скриптах действительно легче и приятнее написать на котлине, например. И у меня будет стат. типизация, комплишен, рефакторинг, файнд юзадж итд
А Роману, наверняка, на го
На скриптовых хорошо писать скрипты. В один экран. Из двух файлов. Или несложный сайтик.
Как писать скрипты на go, я представляю слабо, это же мунспик для 99% программистов (хотя учитывая местные нежные чувства к перлу, неудивительно, что ты его упомянул).
Котлин действительно лишён вышеуказанных недостатков. И в общем тебе прямо сегодня ничто не мешает писать 90% того, что пишется на скриптах, на котлине. Ты готов?
Как и руби
Как и перл
>> Ты готов?
Не всегда.
1) в некоторых окружениях может не быть JVM
2) у меня есть проекты на джанге и фласке. Джанга на котлине не реализуема.
- absolutely. Кроме макожобсов, сидящих на герыче, никто на этой шняге не будет писать в здравом уме.
> в некоторых окружениях может не быть JVM
- в некоторых окружениях может не быть python. Или будет python, но не будет python3. И в каких таких окружениях не будет JVM? На винде разве что, где нужно будет next -> next -> next -> finish.
> Джанга на котлине не реализуема
- джанга нет, но какой-то сервак должен быть реализуем, нет?
ну нет, RoR еще сущестует. Мне руби нра, но я признаю что без предварительной подготовки не прочитать код
>> в некоторых окружениях может не быть python
Тоже верно, но обычно он там есть в каком-то виде, если тебе надо на серваке скриптец то лянотно ставить JVM.
>> но какой-то сервак должен быть реализуем, нет?
Разумеется, они даже есть. Но в Django много магии, которая на ЯПах со стат. типизацией не реализуема. Зато она сохраняет кучу бойлерплейта.
Это трейдофф всегда. Но в целом писать что-то огрмное, сложное, над которым будет работать 20 человек, где будет 300 концепций, писать такое на скриптовом языке в 2018 году я бы не стал
- ну вот галера, которая лабает kabanchik.ua, prom.ua (и возможно их аналоги для российского рынка), содержит около сотни питонорабов, пока не потонула. Да, это не гугл, да, это не хайлоад, но who cares
не дай бог кому переименовать поле user в huuser в проекте где 100 разрабов на питоне
Кстати, это ж вроде задача devops'а, накатить такую миграцию?
Ты до такой степени не понял о чем я, что мне даже стало страшно. Давай я попробую снова:
В языках со статической типизацией вроде Java, Kotlin или C# ты (при условии неиспользования рефлексии конечно) про каждый метод можешь сказать где он объявлен.
Для каждого метода, филда и пр. всегда можно легко дойти до его объявления.
Этим пользуются IDE чтобы поддерживать рефакторинги вроде "rename method".
Ты переименовал поле user в owner, и IDE сама нашла все его вхождения и переименовала, а другие user она не тронула.
В динамических языках сделать такое крайне сложно. В питоне чуть легче, в руби сложнее, в JS еще сложнее.
Потому ты легко можешь сломать код таким рефакторингом.
В компилируемых ЯПах ты узнал бы об этом на этапе компилации, но в питоне -- нет. Остается уповать на тесты.
Всё это не имеет проблемы кода
1) каждый разработчик понимает ВСЮ систему (про каждый "user" он может сказать тот это самый user или другой)
2) весь код покрыт тестами и такие проблемы сразу же всплывут
К сожалению, так бывает только в кино. В жизни приходится ковыряться в недокументированном дерьме на 800 строк без единого теста и пытаться что-то там понять (кстати, CTRL+click в Java перенесет тебя на декларацию/дефиницию, а в питоне далеко не всегда ибо IDE может и не знать).
Потому мне и кажется что большой проект с обычными (а не супергениальными) программистами на питоне поддерживать сложнее, чем аналогичный на Java.
В DI, сериализаторах (в json например), в ORM. Но обычно она поддерживается IDE боль-мень.
пример: Spring (DI контейнер) позволяет в XML описывать бины (пишу по памяти, не видел 10 лет, синтаксис может быть и не такой, но смысль понятен)
Мы создали синглтон курочки и установили ее в одноименное свойство питушка.
По сути вызвался метод "setKurochka" у класса Pitushok (всё это мутабельно и вообще говно, но речь не о том сейчас). Ну вот тут мы использовали рефлексию, но Idea это поймет и будет статически проверять.
>>Но где ты видел проект на питоне где работает большое количество проггеров?
Так Desktop писал же про 100 разрабов:)
В идеальном мире конечно проект надо разбивать на маленькие, независимые сервисы и делать команды на 5-6 человек максимум (и скрам так учит) но не всегда так бывает
- ковыряться в недокументированном дерьме на 800 строк одинаково приятно что в Питоне, что в крестах, что в перле (ну ок, тут вдвойне приятнее).
Да, есть проблема, о которой ты говоришь. Но есть много вариантов её решения или уменьшения. Так что проблема опять-таки в техническом менеджменте.
Ну и конечно я более, чем уверен, что питонячья макака обходится большому папке дешевле жабового гамадрила. Шах и мат, идеалисты
Не совсем. Быстро что-то найти все таки проще когда у тебя работает find usage в Idea. Но с другой стороны чтобы реально ПОНЯТЬ как что-то работает тебе всё равно придется читать код: что на питоне, что на жаве.
Но прыг-прыг-фикс-хуяк на джаве сделать проще. Ну и хотя бы копеляция тебе даст хоть какую-то слабую уверенность что ты вообще не разнёс все к хуям.
>> питонячья макака обходится большому папке дешевле жабового гамадрила
Это не всегда так, если судить по hh (как ни странно!).
В жавке есть еще всякие ништяки. Например есть омуденные профилировщики, даже обычный YourKit и тот хорош (это примерно как ваши Apple Instruments/dtrace, но по проще).
В питонячьем сообществе многие вообще не знают что можно профилировать (там даже про дебагер не все знают!) и похожих инструментов, увы, нет.
Ну и так, по мелочи хуйня всякая типа многопоточности нормальной (которая конечно не так важна в мире микросервисов и облаков)
Есть реальный мир джунов, где народ не сильно в курсе, что можно делать dev, stage и prod, а не хуячить всё в одном окружении на боевом серваке; слово Swagger тут никому ни о чём не говорит. Тут тоже разницы, на чём писать, нет, всё равно получится треш
Ну а у тебя мир вечных мидлов, которые умные слова уже знают, а что с ними делать нет.
Казалось бы: Apple, Google и MS могут позволить себе самых лучших программистов, но студия xcode и android studio всё равно иногда глючат
И узнать об этом далеко не сразу, и, возможно от недовольного заказчика.
Ну вроде как в современном вебе это считается хорошей практикой.
Попробуй спросить вебщика почему вместо XHTML теперь HTML5 в котором можно не закрывать таги, и он тебе объяснит что если ты случайно забыл закрыть таг в XHTML (при верном контент тайпе) браузер покажет ошибку, в HTML5 все равно отрендерит страницу, просто кусочек ее не покажет.
Бывает так, что верстун напутал с тагами и footer страницы не виден, и этого долго никто не замечает, а с XHTML сразу бы заметили.
Те же самые аругменты они используют когда я спрашиваю почему xml-based шаблонизаторов больше не делают.
Ну и когда речь про выбор языка со стат типизацией то, вероятно, они руководствуются тем же:
а зачем мне узнавать про ошибку в CI сервере, если можно узнать от нее от заказчика случайно через пол года?
в начале нулевых было дофига шаблонизаторов на xml (и xslt конечно же).
Они имели отличную поддержку от IDE (потому что их легко парсить) и были защищены от перепутанных и незакрытых тагов.
Потом все сказали что это сложно и нипанятна, и стали использовать НЕ xmlные шаблонизаторы.
Стало можно писать вот так:
.
Разумеется никакие IDE нормально это не хендлят и проверить что все таги закрыты тоже статически никак нельзя.
И все страшно радуются: ах, как теперь стало удобно.
Держится более-ли-менее разве что JSPX: остальные слились
>>А xhtml руками писать не очень удобно.
а html5 удобно? В чем разница?
Алсо, в XSLT можно было наматчить шаблон на какую-то ноду: например если у тебя есть хотя бы один элемент в коллекции то шаблон вызовится, а если нет от не вызовится. Во всех совремменных надо явно писать if, и это оцтой.
как проверяешь то?
>>Ну html был изначально сделан под ручное написание жи.
xhtml это тоже html
>>xml - переусложненное говно и ненужно.
как и статическая типизация, как и IDE как и SOAP. Надо писать на JavaScript в Notepad++ и всё будет хорошо
Пессимистично, как джавка делает с final. Будет ругаться на некоторые вполне валидные конструкции, но в целом сойдёт.
> Пессимистично…
Что такое «проверять пессимистично»?
Уход от XML-based шаблонизаторов в хипстоту это, суть, уход от статической проверки шаблонов на велл-форменность (и даже, о ужас, на валидность если есть схема!).
Это ровно так же самая проблема что и с уходом от стат типизированных ЯПов.
Тобишь чтобы получить гарантию отсутствия незакрытых или перепутанных тегов, которую ты получал статически за 2 секунды в xml, тебе надо покрыть 100% кейсов тестами.
Поскольку статически доказать это покрытие невозможно, остается только запускать тесты с code coverage и надеяться что все куски твоего шаблона рано или поздно выполнятся.
Чуваки взяли, и выкинули на помойку огромный пласт работы, который делал компьютер, и стали делать его сами.
Для этого тебе надо запустить приложение, и тестами проверить все его состояния.
проблема точно такая же как и с отсутствием стат типизации:
в xml ты статически, Без запуска приложения поймаешь
"<b></b></b></b"
Точно так же как в Java ты поймаешь 2 +"petux".
А в сраных джановых, например, шобланизаторах ты этого не поймаеешь.
>>А html это не xhtml
и? В каком месте xml сложнее htmlя?
>>Ну дай нормальный юз кейс xml.
Мне кажется я уже тыщу раз приводил, ну ок.
Я делаю сервис с SOAP: я описываю интерфейс, делаю какие-то структуры, пишу джавадоки, жму волшебную кнопку и получаю .wsdl файл./
На другом конце земли сидит программист на C#: он тоже жмет кнопку и получает скелеты для клиента к моему сервису.
У него те же самые структуры и даже доки в них есть!
То-есть если у меня есть структура Rooster с полем age типа int и комментарием "how many birthdays this rooster celebrated" то чувак на ДРУГОМ языке получит тоже самое. С типом и комментом.
Теперь представим себе питушков с REST/JSON.
формальной спецификации у них нет: есть только человекочитаемые описания .json форматов. Синхронизировать ее с кодом надо вручную потому что ничто там типы не проверяет, и доки тоже.
Доходит до того что если на клиенте чел со статтипизированным япом то он ВРУЧНУЮ создает датаклассы чтобы в них удобно сериализовывать json.
Вот в первых юниксах не было .h файлов и надо было структуры вручную собирать по мануалам.
Но к середине 70х уже поняли что если я делаю API то неплохо бы дать его структуры.
А теперь вот опять откатились в каменный век.
и то и то тюринг полный язык
Вы троллите, или упорно не хотите понять роскомговна, или не знакомы с порблемой останова.
Представьте себе шаблон:Такой код уже никак не провалидировать без проверки всех вариантов ветвления.
А теперь представьте, например, такой код, и попробуйте придумать алгоритм, которым его можно было бы проверить статически:
Это вполне себе проблема, особенно в больших шаблонах с глубокой вложенностью.
>> Каждый день отстреливаешь
Не отстреливаю. Следует-ли из этого что проблему не надо решать?
Я так же не допускаю багов _каждый_ день, значит-ли это что я могу не писать тестов?
У меня достаточно редко (ну раз в месяц где-то) бывают конфликты мерджа, значит я могу отказаться от VCS?
>> и это сразу заметно по разъёбаной верстке.
Совершенно не всегда. Я видел примеры верстки которая едет на конкретных резолюшенах, или у которой незаметно отваливается футер или проблема взлетает только при определенном поведении пользователя (ибо много клиент сайда)
Кроме того в случае XML IDE может построить дерево статически и буквально подсказать тебе какие таги ты можешь где использовать.
Anyway, если какую-то проблему можно бесплатно решать с помощью компьютера, то зачем её решать вручную?
Просто потому что я могу её решить?
Ну так я и без подсветки синтаксиса могу писать, давайте от нее откажемся.
> Проблема статической валидации парности тегов - это охуеть пиздец важная проблема?
Во-первых, если вы считаете, что это не важная проблема, зачем вы утверждаете, что она разрешима, вместо того, чтобы утверждать, что она не важна? Итак, остановились на том, что в общем случае она не разрешима.
Во-вторых, разговор идёт не о важности незакрытых тегов, а о дисциплине веб-программирования в целом. Например, нам известно, что легко было бы сделать так, чтобы все теги гарантированно были закрыты. Средства для этого давно существуют и их назвал роскомговно. Но почему-то настойчиво и во всех пунктах сообщество выбирает в пользу решений, в которых статическая проверка невозможна ни в какой мере. Так же поступает и стандарт: разрешает разработчикам так поступать, попуская незакрытые теги и так далее. В чем профит — сказать трудно, видимо всем важно, чтобы валидировалось вообще что угодно, набранное на клавиатуре, и писать сайт могли даже шимпанзе, которых я очень люблю. Если речь идёт действительно о компьютеризации приматов, я — за.
Лолчто
Язык тупой до безобразия, в либе полно всякого добра, для всяких скриптов норм подходит (уж лучше это говно, чем Python).
Мне тоже в Питонии не нравится излишняя динамичность, runtime-errors driven development и может что ещё, но для скриптов/тулзей это ок.
А по поводу серваков я в соседнем треде скинул ссылки три на бэкенд-фреймворки на Swift'е. На убунту взлетит
ну и jvm под линуксы от оралка, кмк, более серьезна чем core.net
Так сложно при случае воспользоваться "intval" в "PHP" или "*1" (даже не "ParseInt") в "JavaScript"?...
Если у тебя больше одного года опыта то ты почти никогда не нуждаешься в SO
Иногда официальные доки куцы и не покрывают всех нюансов, примеры не полностью документированы, а все туториалы дальше этих самых примеров носа не суют. Это случай фирмы Эппл (см., например, CallKit)
Фреймворк может быть непонятен даже тому, у кого 25 лет опыта писания на этом языке.
Речь же шла о том, что если возникнет тупой вопрос по go то на него сложнее найти ответ чем на PHP./
Ну, разве что именно ты его и написал! Файка Борманда
Если у меня проблема со Spring, но мне пофиг на Kotlin я или на Java.
Если у меня проблема с UIKit, но разве важно пишу на свифте или на objc?
- на SO это обычно две разных категории ответов (т.е. тегов), или же в ответах есть и про то, и про другое, в самых модных случаях авторы ответов указывают варианты для обоих языков. Потому что иногда реально есть разница, ведь это же разные языки, верно?
>>разные языки
работа с CallKit отличается для objc и swift?
- если вопрос про фреймворк, то да.
> работа с CallKit отличается для objc и swift?
- честно не ебу, в целом API, понятное дело, одинаковый, но осознавать те же enum'ы иногда мучительно больно.
А, если говорить про фреймворки не от Apple, то там вообще иногда отдельные версии под ObjC и под Swift, в Realm вроде так.
З.Ы. По тем же крестам иногда приходится смотреть т.к. тонкие моменты в стандарте сложно отыскать.
зы:попадалась либа вообще не документирвоанная. Никак. Максимум пара примеров. В последнее время таких все больше. Думаю, надо за такие либы пиздить.
Больше одного опыта в чём? В 80% процентов случаев я нахожу ответ пока пытаюсь сформулировать хороший вопрос на SO.
У нас ещё есть аналог SO внутри компании, я им постоянно пользуюсь, когда нужно нетривиальные вещи о работе или дизайне внутренних сервисов узнать.
https://en.wikipedia.org/wiki/GLEAM
там не принято шутить про говно и хуи, потому что у многих кишка тонка
в программировании.
Вы все как-то умудрились не понять что я говорю.
Собесеник сообщил что писать на go сложнее чем писать на PHP потому что ответов на вопросы по языку на SO будет меньше.
На что я сказал что обычно хорошему программисту достаточно книжки и референса по языку чтобы с ним разобраться.
Если такой программист задает вопрос на SO, то обычно он связан алгоритмами или API фреймворков, ОС итд, но не самим языком.
То-есть вопросы "как проитерироваться по такой-то коллекции" сеньёры обычно не задают.
Борманд правда отметил что с С++ это не так, ну окей: наверное в с++ можно что-то не понять в стандарте и с 10 годами опыта
>> В 80%
Ну так это же rubber duck debugging. Хороший вопрос -- половина ответа.
>>аналог SO внутри компании,
Вам везет:) У нас есть какие-то статьи на конфлюенсе, какие-то видео со внутренних выступлений и канальчик в слаке, но самое распостраненное решение это "подойти к Васе и спросить как пользоваться его сревисом". И это дико расстраивает
Ленивые все стали. Нынче не то что давеча
- прочитал как guillotine
https://embedy.cc/movies/c0lkbEhCOWlUTzhpSUI0TFQrVlV5YU5hYjIvb1FF eGxLZEc1ZEE2blp1RT0=
Правда я не совсем понял, о питоне ты или о рнр.
или я сделал тоже самое с php (там вроде можно явно указывать типы) и с помощью zend скопилировал его
ну, я все еще программист на интерпретируемых япах?
кстати, у Kotlin есть repl консоль. А уж про груви я и вовсе молчу: она как-бы скриптовая но компилируетс яна лету
В то же время Java, Scala, Kotlin-программы распространяются в скомпилированном виде, и все стремятся научить свои языки компилироваться в джава-байткод для переносимости и вообще, потому что на миллиардах устройств для этого уже всё готово.
Такая мысль меня посетила, вкинул для дискуссии. Рушится вроде как об JS. Тот нихуя не переносим, и считается компилируемым при этом.
В юниксах это вообще классический путь. Большинство юниксов сейчас имеет предкомпилированные пакеты для большинства программ, но есть же gentoo и arch, да и бздуны делают пекеджи не из всех портов, есть слаковые slackbuilds которые тоже тянут исходники.
Как эротично звучит...
Хуй, подтверди!
И в 2к18 лет тащить сайд-эффектные фичи сишкоязыков. В целом конечно насрать, поскольку питон дальше калькулятора не использовал.
И то клеймо...
можно подробнее?
>>and preferably only one—obvious way to do it
compared to ruby and perl -- yep
Особенно удивительно слышать такое от Борманда…
horizontal ellipsis? Серьезно? Ты это вручную делаешь или у тебя автозамена?
Я тоже всегда так делаю…
А вот за правильные тире и кавычки вы достойны всяческих респектов. Вы еще может и ёшки ставите?
…
...
Уже за это его можно ставить. Кроме того, фанатичность и одержимость подсказывают: если многоточие считается единым знаком препинания, значит должно обозначаться одним символом. Паранойя вторит: один символ ни при каких обстоятельствах не окажется разбит на несколько строк (хотя нынче и просто точки не переносятся). Ну и, наконец, использование таких символов показывает, что я очень крутой.
Ёшки — ты имеешь ввиду буквы «ё»? Ну, у меня уже рефлекс после клавиатурных тренажёров. Я если даже захочу, с трудом получится везде «е» ставить.
Но, повторюсь: он мог и спиздеть.
Забавно: символ "..." используется для обозначения varargs в Java и Lua.
Лень проверять, но уверен что … там не сработает
Я тебе и без проверки скажу: не сработает, и хорошо, что не сработает. Не хватало ещё такую дрянь жрать.
юзай dc(1)