- 1
Почему пхпшники получают поболя крестоблядей?
Кресты / Говнокод #25198
0
Почему пхпшники получают поболя крестоблядей?
Запостил: 
crestoblyad,
(Updated )
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
- "PHP" (6227)
- Куча говна (4357)
- Кресты (2940)
- ЙажаСценарий (2225)
- Си диез (2080)
- Jawa (1688)
- Няшная (1340)
- Змея (894)
- Школоло (781)
- mysql_real_escape_string (579)
- Бухгалтерия (547)
- ДействиеСценарий (419)
- Beri bash i ebash (298)
- Яuбy (294)
- Субъективный Си (290)
- =()= (267)
- Школоло (200)
- Сборный (158)
- Метатабличный (91)
- Хламидомонада (75)
- Ябло (Свежее) (49)
- Goвно (37)
- Koko (17)
- HTML (1)
я недавно видел lua знаете где?
в VLC!
Возможно, вы имели ввиду "попоболя"
Яндекс хороший, я не обижусь. Вот если бы ты mail.ru пригрозился, тогда да, пришлось бы inbox реанимировать
Что это означает? Я им пользуюсь и он лучше обычного гмейла. Лучше бы им закрыть гмейл с его уебанским неработающим UI, а по адресу mail.google.com разместить инбокс.
> Яндекс хороший
Мне в нем во входящие мимо спам-фильтров регулярно сыпется откровенный фишинг уровня как заработать 300к в секунду не выходя из дома. И это на нигде незасвеченый адрес. В мейлру, над которым все насмехаются, антиспам получше будет.
Inbox by Gmail is going away at the end of March 2019. The new Gmail has a fresh new look built with top Inbox features like snooze, nudges and more to help you get more done.
> а по адресу mail.google.com разместить инбокс
ходи на inbox.google.com, можешь ещё целых три месяца наслаждаться.
> неработающим UI
УМВР
> ещё целых три месяца
В этом и проблема и причина моего исходного поста.
> УМВР
Я не буду покупать топовый iMac и пересаживаться на хром ради кривого гуглового поделия.
ты шестым эксплорером на windows xp пользуешься?
Почему именно iMac?
А все мои знакомые любители Apple используют OS X вот уже 19 лет как
> macOS [ˌmak ˌoʊ ˌɛs] (изначально была представлена как Mac OS X, в 2012 переименована в OS X, в 2016 переименована в macOS)
фу, поручик
> УМВР
Видимо, на машине для тестов сервисов с 128ГБ памяти и 32 ядрами.
Даже тормознутые говноIDE можно понять. Там хотя бы какие-нибудь фичи по ещё более умному отлову ошибок можно добавлять, более умный частичный парсинг и онлайн подсветку ошибок.
Но гпочта даже не работает в оффлайн режиме, она становится бесполезной сразу после отключения от интернетов, даже свежее письмо не открывается. То есть все алгоритмы гоняются на сервере, почта в браузере - лишь аналог терминала к мощной машине, которые умели строить ещё в 60-70 годах так, чтобы не тормозило. А никаких полезных сложных клиентских алгоритмов и полезных ресурсоёмких фич так и не добавилось.
В ноутбуке тоже.
Я почту вообще никогда не закрываю, она загружается ровно один раз при запуске браузера и дальше не особо тормозит.
На 32 гигах тоже норм, почти не тормозит.
IMAP и ThunderBird?
Не, не слышал
Thunderbird содержит тонны кода, множество клиентских алгоритмов для работы с почтой в оффлайне. Но не тормозит как сраная вкладка, которая только и делает, что посылает пару запросов к серверу, на котором крутятся алгоритмы.
Сраную вкладку написали твои коллеги, жс-программисты, на твоём любимом языке программирования. Им важно чтобы работало и чтобы было красиво, а не ковыряться в низкоуровневом говне (за такое промоушенов не дают). Всё по твоим же заветам.
Ковыряние в низкоуровневом говне в нашем веке не так сильно связано с пирфомансом. Сейчас в говне ковыряются автоматика (движки, конпеляторы) и создатели автоматики. И это правильный подход. В говне ковыряются один раз, а затем переиспользуют в библиотеках и компиляторах. Ежепрограммное ковыряние в низкоуровневом говне - пережиток прошлого, а не признак особого ума или выдающихся способностей программиста. Это то же самое, что и http://govnokod.ru/212.
У веб-питухов под боком был отдел в8-питухов, у которых можно было спросить о том, как не слить пирфоманс в своём же браузере. У них был профайлер в их же браузере и, я надеюсь, отдел тестировщиков.
Но в говно всё скатилось потому, что во-первых, менеджерам нужны отчёты о прогрессе (если программа работает, надо это исправить, вводя новые баги и фичи для имитации прогресса, и нефункциональные изменения вроде оптимизации за благо не считаются), а во-вторых, компании нужны не радостные пользователи, а более эффективный показ рекламы. В этом случае глючащий интерфейс ценится больше потому, что пользователь будет его перезагружать и смотреть новые рекламные объявления.
Курочка по зёрнышку клюет, а ведь двор в говне.
Программисты на С++ пишут более-ли-менее быстрый код, и разбираются в алгоритмах.
А программисты на JS разбираются только в смузи, потому у них и код такой
Если ты не знаешь что такое смузи, то ты наверное и UI на электроне никогда не делал
а я думал он сразу берет нейтив реакт
Чуть менее, чем все ядра программ уже написаны. Если вдруг что остаётся, над алгоритмами уже поработали математики, тупому кодеру достаточно только перевести их на язык программирования и учесть его недостатки перед математикой (педерача по ссылке, отсутствие сборки мусора, небесконечность записи чисел). Максимум -- придётся скобенировать из нескольких шаблонных алгоритмов один свой.
Область UI же так хорошо не исследована, в ней меньше готовых ответов. В отличие от математических алгоритмов здесь не установлены явно пределы оптимизации, асимптотика алгоритмов работает на другом конце (не на стороне бесконечности, а на стороне нуля), здесь дополнительное действие - не вклад в пренебрежимо малую O(1), а проблема, которую надо решать. Здесь повторяющиеся действия - залог ошибки, расположение элементов интерфейса влияет на скорость работы с ним, дотягиваемость мышью конфликтует с логическим расположением, удобным для глаз. Интерфейс каждой программы - уникален, а создание удобного интерфейса - целое искусство. Нужно соблюдать баланс между удобным минимализмом и полезной функциональностью. И это влияет как на написание программ (больше интерфейс - больше изменяемого состояния), так и на использование (больше интерфейс - хуже в нём разобраться). И если за UI берётся непрофессионал, то выходит неюзабельное говно.
Создание UI - всегда вызов, всегда творческий процесс и возможность пошевелить мозгами.
Создание сервера с API - штамповка стандартных алгоритмов, удел заедушных питушков.
Более правильным было бы сделать хороший пользовательский интерфейс, а желающий мог бы написать сервер под себя.
В конце 19 века председатель американского патентного бюро написал президенту письмо, что надо закрыть патентное бюро так как все уже изобретено.
да, если ты всю жизнь делаешь API для магазинов
Рад что ты с ним согласегн
Я вот продаю жетоны в метрополитене, и мне это нравится. Не понимаю как можно добровольно ебать себе мозг
Жрем зато за так
А кто пашет на заводе
Истинный дурак
Кир Рик начинал с мизинчика...
Программист же -- временное явление. Программист попал под раздачу благ не совсем случайно, но ненадолго. До него этой участи удостаивались писари, художники и фотографы. Большая часть них занималась настолько тривиальными делами, что была выброшена на свалку истории. Переводить реальность на язык холста, фотопластинок или магнитных дисков выгодно только до тех пор, пока только у тебя холсты, фотопластинки и магнитные диски, а вокруг -- бедное необразованное быдло. Стоит ситуации чуть измениться, любой школьник легко повторит твой "успех".
Программист старается придать своей работе важность. В ход идут сложные алгоритмы, стереотипное мышление (этот язык для царей, остальные - говно) и заносчивость. Чем больше напердолился -- тем лучше. Потратить 100 часов на программу на "C++" -- почётнее, чем 10 часов на программу на "JavaScript". И плевать, что память течёт и на обдумывание всех мелочей, решённых в движке JS, не хватило ресурсов мозга.
Программист старается придать своей работе налёт уникальности. У него не хватило ума, чтобы пойти в науку и сталкиваться с неизведанным каждый год. У него не хватило творческих порывов, чтобы пойти в искусство. И теперь программист старается всем доказать, что он находится не на уровне уборщицы, которая выгребает сраную бумагу из постсоветских туалетов, а является членом почётнейшего сословия. Поэтому уникальные алгоритмы и новые фреймворки в его глазах лучше, чем проверенные и надёжные простые решения.
А всего-то нужно было получать удовольствие от своей работы. Человечеству помогают не суперпрограммы с новейшими алгоритмами, а тупой бойлерплейт. Пишешь простые массовые программы -- помогаешь планете.
И знаете что?
Он прав!
В том же перекладывании битов из порта в порт ничуть не больше науки, чем в перекладывании строчек из поля в json.
Х.з., у меня в джаве или питоне возня с ресурсами больше ресурсов мозга отнимает чем в крестах. Хотя может просто чуть больше опыта надо, чтобы на моторной памяти ебашить эти ваши close().
нет, если ты fpm или mod_php
да если ты cgi
просто утекает дескрпитор и все
закроется сам собой со временем когда apacheый детеныш помре
в джаве нет
в C# есть using, и потому я за C#
а в питоне и джаве в этом случае придется чистить вилкой
ёршика там нет, потому что принцессы не какают
Вариант 1. Глобальная переменная или неудаляемая переменная в куче
Переменная один раз инициализируется, живёт всегда.
Объявление + одна команда на инициализацию в C++; 1 команда на инициализацию в python.
Вариант 2. Переменная с ограниченным временем жизни.
В C++ переменная создаётся внутри фигурных скобок, внутри тех же фигурных скобок сидит код произвольной сложности.
В python переменная создаётся в блоке with, внутри блока сидит код произвольной сложности.
Вариант 3. Переменная с пользовательским временем жизни.
В C++ одной командой создаётся, одной командой удаляется.
В python одной командой создаётся, одной командой очищается.
Вариант 4. умные указатели.
Здесь, с одной стороны, в python работает более мощный GC.
С другой стороны, никто не мешает напейсать свой подсчёт ссылок в python и использовать для хранения расшариваемых полей внутри объектов, с которыми работают через with.
Я бы так классифицировал (если отбросить объекты без ресурсов, т.к. с ними GC справляется идеально):
1) Объектом владеет скоп. Тут спасает with.
2) Объектом владеет программа. Всё ок. При желании можно свести к 1 через with в main().
3) Объектом владеет другой объект. Пришло время позвать close() из close(). Бройлерплейт, но жить можно.
4) Объектом владеет несколько других объектов. Удачного подсчёта ссылок (в итоге всё сводится к 1+3) и аккуратной работы с back ссылками.
5) Объектом владеет хуй пойми кто - типичная хуйня от сишника. Добро пожаловать в ад (на любом языке).
Вот в крестах 3 (и 3 как часть 4) не требует дополнительного кода.
Знаешь, я видел сишкококод под апи операционок, итам обычно всегда было понятно кто им владеет
Вот прямо в документации написано. Берешь, и делаешь. И всегда понятно кто Девушку создал и кто ее танцует и кто ей делает free().
Может быть просто некоторые козоёбы не могут в такие тонкости, и у них память выделяется и очищается в случайном месте?
В питоне для этого таки можно заюзать ExitStack. Можно ли штатными средствами вырвать объект из цепких лап with в джаве или шарпе - хуй знает (в принципе можно замутить аналог ExitStack).
Ну и объекты начинают делиться на первосортные (только память) и второсортные (с ресурсами). Причём любой объект, который сохранит в себе ссылку на второсортный, зашкваривается вместе со всем использующим его кодом...
указан 1988 год. Так что как минимум в С89 сборщик мусора уже был.
a=Foo("a.bin")
b=Foo("b.bin")
return Bar(a, b)
Примерно такой паттерн, но без утечки ресурсов при исключениях.
А про второсортные объекты: понадобилось тебе хранить ссылку на Bar в каком-нибудь объекте - теперь он тоже зашкварен об ресурсы и требует with, close и т.п. И все, кто хранит ссылку на него тоже.
Благо ExitStack завезли. А вот в джавке и шарпе - вроде только траи.
https://www.govnokod.ru/24902#comment434772
> оно мне не нужно
Если твоя программа умирает на первом исключении, то тебе это не нужно.
try-with-resources с седьмой джавы есть.
Но всё же возня с владением ресурсов должна быть более жёсткой. Без неё даже простую функцию не напишешь: объект либо скопируется лишний раз, либо утечёт.
Ну концепция владения - не rocket science. В общем-то она и в языках с gc помогает в аморфный пиздец не скатываться.
Достаточно сравнить архитектуру unix, и классического смузиприложения
> unix, и классического смузиприложения
А ещё в СССР была отличная бытовая техника. Вон дедушкин пылесос ещё работает, а современный давно издох. И никто не говорит о том говне, которое сломалось и не дожило до наших дней. Дедушкин пылесос Unix дожил до наших дней, то это потому, что над ним тогда хорошо попотели. Если бы пылесос Unix писался на более высокоуровневом языке, он бы не был хуже.
Пердольство с памятью требует людей, которые способны пердолиться с памятью, полезный выхлоп которых -- хорошие архитектуры. Если не собрать специально обученных людей, пердольное приложение вовсе не получится.
В случае смузитехнологий можно выбирать. Либо получать быстро и дёшево работающее приложение, либо набирать пердоликов, которые выдадут топовые архитуктуру и код.
Именно потому системы получаются более лучшие чем те, которые проектируют прочитавшие "PHP за 24 часа" Дениса Попова
Разумеется. Большинство вообще не готовы платить за программирование. Самая распостраненная работа это дворник.
Если ты хочешь решать интересные задачи сидя в хорошем офисе с умными людьми и получать за это хорошие деньги, то тебе должно быть насрано на "большинство".
https://coinspot.io/world/port-valensii-poumneet-blagodarya-blokchejnu/
Вот, кстати, +1. За свою карьеру несколько раз приходилось использовать большие сложные алгоритмы, и программист, как максимум, пишет реализацию существующего алгоритма из статьи. А придумывает алгоритм в лучшем случае postdoc researcher из той же компании, а то и вовсе аспирант из какого-нибудь университета. Потому что, внезапно, компании не готовы проводить исследования и изобретать новые алгоритмы. А если готовы, то они нанимают для этого профессиональных ученых, а не быдлокодера васю со средним специальным. Внезапно, программисты не создают алгоритмы. Я не сразу понял этот тренд, а когда понял, для меня это стало озарением и разочарованием.
Не нужно создавать алгоритмы, их уметь применять. Я вот в свободное время пишу либу на хачкеле с батарейками для юнит-тестинга, которая будет выдавать вменяемые сообщения об ошибках, так у меня там алгоритмических задач хоть отбавляй (ахо-корасик для зожатия пачки объектов быстрее, чем за квадрат, perfect-matching на двудольных графах ну и по традиции всякий унылый парсинг).
Я вот в свободное аремя дрочу в присядку. Твоя зарплата от этого зависит?
зарабатывать этим так пошло и низки
Ну вот смотри, пример из жизни: у нас в городе есть как минимум 3 компании (Digital Asset, DFinity, Concordium), готовых платить очень хорошие деньги за разработку Смузи-Блокчейна™ на хачкеле (а некоторые даже за формальную верификацию).
Первым же делом на собеседовании тебя попросят показать какой-нибудь код на хачкеле, который ты написал.
Так что да, моя зарплата потенциально зависит от этого. Хочу ли я пилить смузи-блокчейны — отдельный вопрос.
а как это?
Блендер справится с пельменями?
[1] https://www.youtube.com/watch?v=rsWs-xYStFo
Отдельным отсеком внизу.
Я в гермашке в чем-то вроде лагеря видел советский Днепр
Я себе тоже блендер летом купил, молочные коктейли делать. Теперь я — хипстер?
Вот это был крафт!
Смузи запивали
Они не понимали.
Ну ты учи машину, кликай в "Spam!". Всё зависит от тебя, гуест.
Осторожней с этим, а то в один прекрасный момент уже он тебя пошлёт нахуй. У меня древнее мыло на яндексе так проебалось.
Я думал, речь о приезде внезапных гостей, хотя это у другого почтовика.
Насколько законны такие вымогательства? Хотя это же рашка... Или хуяндекс голландский?
Ну вобьешь новый если одновременно учетку не проебал.
А что незаконного? Они пытаются тебя "спасти" от взлома. Фейсбук вон вообще без сотика неюзабелен.
>Ну вобьешь новый если одновременно учетку не проебал.
но если сотовый для логина не нужен - то это будет не двухфакторная аутенификация, а однофакторная. А телефон им нужен для других целей.
Ещё yubikey есть, удобно.
Не мог я сразу от 2-х акков пароль забыть, я эти пароли даже до сих пор помню, тем более один из парольэй я часто юзаю.
В настоящий момент вся ваша почта переезжает на сторонний почтовый сервис.
Как следствие, освободилось 250 серверов, которые мы будем рады продать любому желающему. Мы не имеем понятия сколько это стоит, поэтому ждем ваших предложений на email buyservers@corp.qip.ru
Вот ссылка на список серверов - servers.xlsx
Гугл находит этот адрес ровно на двух страницах — на ГКшечке и каком-то сраном форуме, причём на последнем он был опубликован всего три дня назад. Успех!
На сайте QIP написано, что они передали свой сервис Яндексу, поэтому по всем вопросам теперь обращаться к Яндексу. На сайте Яндекса написано, что QIP им передал не всё, поэтому они не виноваты в том, что нихера не работает.
У меня дежавю. Похожая ситуация была при переезде Народ.ру на Ucoz, когда проебали половину сайтов. Яндекс писал, что все сайты передали Юкозу, поэтому обращаться к Юкозу. Юкоз писал, что Яндекс им передал не всё, поэтому обращаться к Яндексу.
А ещё интереснее было, когда Апорт передал свою почту в /dev/null.
Кстати, домен pochta.ru был захвачен Почтой России, но ящики до недавнего времени удалось сохранить (логиниться надо было на qip.ru, а не на pochta.ru).
Вообще кто же знал, что в РФ электронная почта когда-нибудь сосредоточится у трёх гигантов ("Mail.ru", "Яндекс", "Gmail"), а остальные окажутся не нужны?
мну помнит как продавали почту.
Некоторые ISP разрешали по дешевке купить только почту без выхода в Интернет
в некоторых инстах были и вовсе UUCP
С компанией, в которой работаешь ты, нет
— vsl, 2007(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88517
> Virtual-base class class constructor with for-loop with initializer list referencing local variable not executed
Как всё сложно, виртуальные классы, конструкторы какие-то, локальные референсы
Если так подумать, нет ни одного соответствующего стандарту C++ компилятора. Любой компилятор крестов содержит n-ное количество багов, и некоторые из подобных багов живут годами. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 например этот баг живет аж с 2011 года, чего-то там в неймспейсе находит, но не должно находить.
> This should be rejected, but lookup using associated namespaces finds operator== in the global namespace. It should only look in namespace A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87208 и вот это еще, этот относительно недавний, но тоже косяк с этим перегрузочным бредом и неймспейсами
https://en.cppreference.com/w/cpp/language/adl
> Argument-dependent lookup, also known as ADL, or Koenig lookup, is the set of rules for looking up the unqualified function names in function-call expressions, including implicit function calls to overloaded operators. These function names are looked up in the namespaces of their arguments in addition to the scopes and namespaces considered by the usual unqualified name lookup.
https://en.cppreference.com/w/cpp/language/template_argument_deduction а еще вот это
Посмотрите сколько текста о каких-то мутных особенностях языка что вот там какая-то дедукция через вот что-то там
— j123123, 2018
Имненно поэтому я за Forth:
https://colorforth.github.io/1percent.html
There is no syntax, no redundancy, no typing. There are no errors that can be detected. Forth uses postfix, there are no parentheses. No indentation. Comments are deferred to the documentation. No hooks, no compatibility. Words are never hyphenated. There's no heirarchy. No files. No operating system.
ты бабай
давай скорей отсель съебай!!
https://pbs.twimg.com/media/DumYoZaWsAAMJ0r.jpg