- 1
Почему пхпшники получают поболя крестоблядей?-
C++ / Говнокод #25198
−1
Почему пхпшники получают поболя крестоблядей?
Запостил:
crestoblyad,
16 Декабря 2018
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Возможно, вы имели ввиду "попоболя"
Яндекс хороший, я не обижусь. Вот если бы ты mail.ru пригрозился, тогда да, пришлось бы inbox реанимировать
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?
> УМВР
Видимо, на машине для тестов сервисов с 128ГБ памяти и 32 ядрами.
Даже тормознутые говноIDE можно понять. Там хотя бы какие-нибудь фичи по ещё более умному отлову ошибок можно добавлять, более умный частичный парсинг и онлайн подсветку ошибок.
Но гпочта даже не работает в оффлайн режиме, она становится бесполезной сразу после отключения от интернетов, даже свежее письмо не открывается. То есть все алгоритмы гоняются на сервере, почта в браузере - лишь аналог терминала к мощной машине, которые умели строить ещё в 60-70 годах так, чтобы не тормозило. А никаких полезных сложных клиентских алгоритмов и полезных ресурсоёмких фич так и не добавилось.
В ноутбуке тоже.
Я почту вообще никогда не закрываю, она загружается ровно один раз при запуске браузера и дальше не особо тормозит.
На 32 гигах тоже норм, почти не тормозит.
Thunderbird содержит тонны кода, множество клиентских алгоритмов для работы с почтой в оффлайне. Но не тормозит как сраная вкладка, которая только и делает, что посылает пару запросов к серверу, на котором крутятся алгоритмы.
Сраную вкладку написали твои коллеги, жс-программисты, на твоём любимом языке программирования. Им важно чтобы работало и чтобы было красиво, а не ковыряться в низкоуровневом говне (за такое промоушенов не дают). Всё по твоим же заветам.
Ковыряние в низкоуровневом говне в нашем веке не так сильно связано с пирфомансом. Сейчас в говне ковыряются автоматика (движки, конпеляторы) и создатели автоматики. И это правильный подход. В говне ковыряются один раз, а затем переиспользуют в библиотеках и компиляторах. Ежепрограммное ковыряние в низкоуровневом говне - пережиток прошлого, а не признак особого ума или выдающихся способностей программиста. Это то же самое, что и http://govnokod.ru/212.
У веб-питухов под боком был отдел в8-питухов, у которых можно было спросить о том, как не слить пирфоманс в своём же браузере. У них был профайлер в их же браузере и, я надеюсь, отдел тестировщиков.
Но в говно всё скатилось потому, что во-первых, менеджерам нужны отчёты о прогрессе (если программа работает, надо это исправить, вводя новые баги и фичи для имитации прогресса, и нефункциональные изменения вроде оптимизации за благо не считаются), а во-вторых, компании нужны не радостные пользователи, а более эффективный показ рекламы. В этом случае глючащий интерфейс ценится больше потому, что пользователь будет его перезагружать и смотреть новые рекламные объявления.
Чуть менее, чем все ядра программ уже написаны. Если вдруг что остаётся, над алгоритмами уже поработали математики, тупому кодеру достаточно только перевести их на язык программирования и учесть его недостатки перед математикой (педерача по ссылке, отсутствие сборки мусора, небесконечность записи чисел). Максимум -- придётся скобенировать из нескольких шаблонных алгоритмов один свой.
Область UI же так хорошо не исследована, в ней меньше готовых ответов. В отличие от математических алгоритмов здесь не установлены явно пределы оптимизации, асимптотика алгоритмов работает на другом конце (не на стороне бесконечности, а на стороне нуля), здесь дополнительное действие - не вклад в пренебрежимо малую O(1), а проблема, которую надо решать. Здесь повторяющиеся действия - залог ошибки, расположение элементов интерфейса влияет на скорость работы с ним, дотягиваемость мышью конфликтует с логическим расположением, удобным для глаз. Интерфейс каждой программы - уникален, а создание удобного интерфейса - целое искусство. Нужно соблюдать баланс между удобным минимализмом и полезной функциональностью. И это влияет как на написание программ (больше интерфейс - больше изменяемого состояния), так и на использование (больше интерфейс - хуже в нём разобраться). И если за UI берётся непрофессионал, то выходит неюзабельное говно.
Создание UI - всегда вызов, всегда творческий процесс и возможность пошевелить мозгами.
Создание сервера с API - штамповка стандартных алгоритмов, удел заедушных питушков.
Более правильным было бы сделать хороший пользовательский интерфейс, а желающий мог бы написать сервер под себя.
Кир Рик начинал с мизинчика...
Программист же -- временное явление. Программист попал под раздачу благ не совсем случайно, но ненадолго. До него этой участи удостаивались писари, художники и фотографы. Большая часть них занималась настолько тривиальными делами, что была выброшена на свалку истории. Переводить реальность на язык холста, фотопластинок или магнитных дисков выгодно только до тех пор, пока только у тебя холсты, фотопластинки и магнитные диски, а вокруг -- бедное необразованное быдло. Стоит ситуации чуть измениться, любой школьник легко повторит твой "успех".
Программист старается придать своей работе важность. В ход идут сложные алгоритмы, стереотипное мышление (этот язык для царей, остальные - говно) и заносчивость. Чем больше напердолился -- тем лучше. Потратить 100 часов на программу на "C++" -- почётнее, чем 10 часов на программу на "JavaScript". И плевать, что память течёт и на обдумывание всех мелочей, решённых в движке JS, не хватило ресурсов мозга.
Программист старается придать своей работе налёт уникальности. У него не хватило ума, чтобы пойти в науку и сталкиваться с неизведанным каждый год. У него не хватило творческих порывов, чтобы пойти в искусство. И теперь программист старается всем доказать, что он находится не на уровне уборщицы, которая выгребает сраную бумагу из постсоветских туалетов, а является членом почётнейшего сословия. Поэтому уникальные алгоритмы и новые фреймворки в его глазах лучше, чем проверенные и надёжные простые решения.
А всего-то нужно было получать удовольствие от своей работы. Человечеству помогают не суперпрограммы с новейшими алгоритмами, а тупой бойлерплейт. Пишешь простые массовые программы -- помогаешь планете.
В том же перекладывании битов из порта в порт ничуть не больше науки, чем в перекладывании строчек из поля в json.
Х.з., у меня в джаве или питоне возня с ресурсами больше ресурсов мозга отнимает чем в крестах. Хотя может просто чуть больше опыта надо, чтобы на моторной памяти ебашить эти ваши close().
Вариант 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) не требует дополнительного кода.
В питоне для этого таки можно заюзать ExitStack. Можно ли штатными средствами вырвать объект из цепких лап with в джаве или шарпе - хуй знает (в принципе можно замутить аналог ExitStack).
Ну и объекты начинают делиться на первосортные (только память) и второсортные (с ресурсами). Причём любой объект, который сохранит в себе ссылку на второсортный, зашкваривается вместе со всем использующим его кодом...
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 писался на более высокоуровневом языке, он бы не был хуже.
Пердольство с памятью требует людей, которые способны пердолиться с памятью, полезный выхлоп которых -- хорошие архитектуры. Если не собрать специально обученных людей, пердольное приложение вовсе не получится.
В случае смузитехнологий можно выбирать. Либо получать быстро и дёшево работающее приложение, либо набирать пердоликов, которые выдадут топовые архитуктуру и код.
https://coinspot.io/world/port-valensii-poumneet-blagodarya-blokchejnu/
Не нужно создавать алгоритмы, их уметь применять. Я вот в свободное время пишу либу на хачкеле с батарейками для юнит-тестинга, которая будет выдавать вменяемые сообщения об ошибках, так у меня там алгоритмических задач хоть отбавляй (ахо-корасик для зожатия пачки объектов быстрее, чем за квадрат, perfect-matching на двудольных графах ну и по традиции всякий унылый парсинг).
Ну вот смотри, пример из жизни: у нас в городе есть как минимум 3 компании (Digital Asset, DFinity, Concordium), готовых платить очень хорошие деньги за разработку Смузи-Блокчейна™ на хачкеле (а некоторые даже за формальную верификацию).
Первым же делом на собеседовании тебя попросят показать какой-нибудь код на хачкеле, который ты написал.
Так что да, моя зарплата потенциально зависит от этого. Хочу ли я пилить смузи-блокчейны — отдельный вопрос.
Блендер справится с пельменями?
[1] https://www.youtube.com/watch?v=rsWs-xYStFo
Отдельным отсеком внизу.
Я себе тоже блендер летом купил, молочные коктейли делать. Теперь я — хипстер?
Вот это был крафт!
Ну ты учи машину, кликай в "Spam!". Всё зависит от тебя, гуест.
Осторожней с этим, а то в один прекрасный момент уже он тебя пошлёт нахуй. У меня древнее мыло на яндексе так проебалось.
Я думал, речь о приезде внезапных гостей, хотя это у другого почтовика.
Ну вобьешь новый если одновременно учетку не проебал.
А что незаконного? Они пытаются тебя "спасти" от взлома. Фейсбук вон вообще без сотика неюзабелен.
Ещё yubikey есть, удобно.
Не мог я сразу от 2-х акков пароль забыть, я эти пароли даже до сих пор помню, тем более один из парольэй я часто юзаю.
Гугл находит этот адрес ровно на двух страницах — на ГКшечке и каком-то сраном форуме, причём на последнем он был опубликован всего три дня назад. Успех!
— 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.