Programming sucks – Telegram
Programming sucks
81 subscribers
12 photos
188 links
Когда вы меняете направление всех стрелок в конусе, вы получаете коконус.
Download Telegram
When you ask somebody what garbage collection is, the answer you get is probably going to be something along the lines of "Garbage collection is when the operating environment automatically reclaims memory that is no longer being used by the program. It does this by tracing memory starting from roots to identify which objects are accessible."

This denoscription confuses the mechanism with the goal. It's like saying the job of a firefighter is "driving a red truck and spraying water."

(c) https://blogs.msdn.microsoft.com/oldnewthing/20100809-00/?p=13203
Then there was another book that everybody thought was the greatest thing ever in that same period—Design Patterns—which I just thought was crap. It was just like, programming via cut and paste. Rather than thinking through your task you looked through the recipe book and found something that maybe, kinda, sorta felt like it, and then just aped it. That’s not programming; that’s a coloring book. But a lot of people seemed to love it. Then in meetings they’d be tossing around all this terminology they got out of that book. Like, the inverse, reverse, double-back-flip pattern—whatever. Oh, you mean a loop? OK.

(c) Jamie Zawinski in «Coders at work»
Раньше CSS писали люди, а теперь — разработчики.

Разработчик — он же как дитя малое — всё в рот тянет.

(с) Макеев, t.me/webstandards_ru/4253
Программисты — это, по-сути, психи. Только психически больному человеку будет интересно сидеть 24 часа в сутки перед экраном и заниматься перемещением единичек и ноликов, вместо того, чтобы, скажем, просто прогуляться весенним днем на солнышке и ни о чем не думать.



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

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

https://habr.com/post/218727/
В сети вы встретите примеры, где из однобуквенных переменных будут собираться функции с ядреной математикой на 200 строк сплошного текста, но то, что кто-то так делает, еще не значит, что это стоит повторять. Подобный подход — это не "специфика работы с GL", это — банальная копипаста исходников еще из прошлого века, написанных людьми, которые в молодости имели ограничения на длину имен переменных.

(c) https://habr.com/post/420847/
JSON is intended to be a “lightweight data-interchange format”, and claims that it is “easy for humans to read and write” and “easy for machines to parse and generate”.

As a data interchange format JSON is pretty okay. A human can read and write it comparatively easily, and it’s also pretty easy to parse for machines (although there are problems). It’s a good trade-off between machine-readable and human-readable and a huge improvement on what it intended to replace: XML, which I consider to be unreadable by both machines and humans.

(c) https://arp242.net/weblog/json_as_configuration_files-_please_dont
Software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia.

(c) cvs@openbsd.org mailing list, https://en.m.wikiquote.org/wiki/Talk:Theo_de_Raadt
Most complicated or broken software is not designed to be overly complex or dysfunctional. It’s just designed to do something other than its intended purpose.

Most programmers want to get paid and have fun at the same time. Of course, the definition of “fun” is different for everyone, but for many engineers, it boils down to tackling interesting and challenging problems that are within the realm of solvability.

The amount of imaginary problems a software engineer can create for themselves is a function of their imagination and of the difficulty of the real problems they’re supposed to solve.

It should be noted that this issue isn’t unique to developers. Management, sales, HR, support, legal, and even accounting departments have their own unique ways of creating imaginary problems. They try to involve themselves too much in a decision, when their presence at a meeting is just a formality or wasn’t requested at all. They overemphasize a minute problem that is related to their role, or hire teams much larger than necessary to illustrate their importance.

When problems are dumb, intelligent individuals will find a way of coping.

(c) https://medium.com/s/story/imaginary-problems-d4f2921bd1b8
I don’t know why everyone wants to be a programmer, and everyone thinks that anyone can learn programming, just like everyone can learn proper grammar. It’s more like art - if you’re not artistic, you’ll never learn” to be artistic, you’ll keep squeaking through art classes without learning much. The same goes for programming - if you’re not analytical*, you’ll never learn to be analytical, so you’ll always be a programmer looking for someone to show you how to solve the problem you’re working on.

*Survival is mainly “fight or flee”. If a lion came at you, 50,000 years ago, you didn’t analyze things, you just hoped that he’d run out of strength before he caught you. Analyzing him for a few minutes didn’t get those “analysis genes” passed on, they became lion food. Humans are pattern-seeking animals. We’re also non-analytical animals. Programming is analytical, so not many of us can actually do it.

(c) https://www.quora.com/As-a-software-developer-who-is-not-good-at-programming-how-do-I-hide-myself-in-a-tech-company-and-not-get-caught-out
The entire idea of slowly working your way up has gone out the window. In fact slowly working your way up is for the skilled or educated who are allowed to do architecture… The unskilled are the ones likely to be slapped with a measurement get 2 points this sprint or you are gone.
(c) https://www.quora.com/Why-are-senior-software-engineering-interviews-so-tough-these-days
There were people who felt that the advent of faster and bigger machines would replace the pinching shoe at most by a fitting shoe, and that, therefore, the economics of program execution would remain a serious concern of the programmer, a concern that would even become more important as size of machines and applications would grow, and, with more complex installations, would pose more difficult problems. Also it was observed that switching from machine code to a high-level programming language did not guarantee all the benefits that were hoped for. In particular, programmers still produced, as willingly as before, large chunks of ununderstandable code, the only difference being that now they did it on a more grandiose scale, and that high-level bugs had replaced low-level ones. They also realized that the advent of high-level programming languages had not reduced the essential need for accuracy: redundancy in high-level programming languages only reduces the ill effects of some inaccuracies.
(c) Edsger W. Dijkstra (https://www.cs.utexas.edu/~EWD/trannoscriptions/EWD05xx/EWD540.html)
Lightweight? Lightweight? What crack are you on?
Sometimes you wonder how anyone could describe this complicated mess as lightweight. The lightweight is in reference to the previous leading standard for directory services, called X.500. The problem with X.500 was that it required the use of the OSI network stack and couldn’t use TCP/IP. It was also rather more complicated. LDAP only uses 9 of the operations that X.500 supported, and can use the simpler TCP/IP networking stack.
(c) https://www.davidpashley.com/articles/ldap-basics/
У Microsoft аналогичная проблема с операционными системами: они годами выпускали лажу, делая ее совместимой с прежней лажей, основанной на всей лаже, созданной раньше.

(c) Крокфорд, Coders at work
Like all of the WHATWG specs, it initially looks like the aftermath of a cluster bomb in a scrabble factory, but once you’ve read it for the 5th time and wiped the blood from your eyes, it’s actually pretty interesting
(c) https://www.html5rocks.com/en/tutorials/speed/noscript-loading/
Like a cluster-bomb in a sheep factory, “defer” became a wooly mess. Between “src” and “defer” attributes, and noscript tags vs dynamically added noscripts, we have 6 patterns of adding a noscript. Of course, the browsers didn’t agree on the order they should execute.
(c) https://www.html5rocks.com/en/tutorials/speed/noscript-loading/
Forwarded from Alexander Granin
В последние пару недель в С++ сообществе разгорелся большой срач по поводу новых фич в C++20. Гемйдев-разработчики стриггерились на пример от Eric Niebler, где он с использованием своей ФП-библиотеки ranges решил задачу "вывести все пифагоровы тройки". Код содержит десять строк с вложенными лямбдами и неявными циклами, и многие олдскульные разработчики находят его нечитаемым и непонятным. В сети одна за одной появились разгромные статьи от ведущих геймдевелоперов про неверное направление развития С++. В Твиттере развернулись баталии с явным и неприкрытым хейтом в сторону "modern C++" и в сторону Эрика Ниблера в частности.
Forwarded from Alexander Granin
Код, на который стриггерились геймдевелоперы:
using view::iota;
auto triples =
for_each(iota(1), [](int z) {
return for_each(iota(1, z+1), [=](int x) {
return for_each(iota(x, z+1), [=](int y) {
return yield_if(x*x + y*y == z*z,
make_tuple(x, y, z));
});
});
});
I can confirm: when I was 13 years old, an older boy invited me over to his house and on his computer he showed me things in Haskell that my young mind was not ready for: foldable semigroup isomorphisms, lenses, comonads and homeomorphic endofunctors. For years afterwards, I've felt dirty and ashamed of my functional programming experience.
(c)https://www.reddit.com/r/programmingcirclejerk/comments/adidn7/haskell_is_very_damaging_to_inexperienced_and/
Generally, programmers aren’t thrilled about the iterative method because it means extra work for them. Typically, it’s managers new to technology who like the iterative process because it relieves them of having to perform rigorous planning, thinking, and product due diligence (in other words, interaction design). Of course, it’s the users who pay the dearest price. They have to suffer through one halfhearted attempt after another before they get a program that isn’t too painful.

(c) The Inmates Are Running the Asylum, Alan Cooper