Programming sucks – Telegram
Programming sucks
81 subscribers
12 photos
188 links
Когда вы меняете направление всех стрелок в конусе, вы получаете коконус.
Download Telegram
Question: What is the origin of STL? Has STL been conceived to be what it is now, that is "the" C++ Standard Library, or does it come from some other project? Could you tell us a history of STL?

Answer: In 1976, still back in the USSR, I got a very serious case of food poisoning from eating raw fish. While in the hospital, in the state of delirium, I suddenly realized that the ability to add numbers in parallel depends on the fact that addition is associative. (So, putting it simply, STL is the result of a bacterial infection.) In other words, I realized that a parallel reduction algorithm is associated with a semigroup structure type.

(c) http://www.stlport.org/resources/StepanovUSA.html
Every time I would look at an algorithm I would try to find a structure on which it is defined. So what I wanted to do was to describe algorithms generically. That's what I like to do. I can spend a month working on a well known algorithm trying to find its generic representation. So far, I have been singularly unsuccessful in explaining to people that this is an important activity.
(c) http://www.stlport.org/resources/StepanovUSA.html
I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.
(c) http://www.stlport.org/resources/StepanovUSA.html
I miss files. I still create many of my own, but increasingly, that seems an anachronism, like using a quill rather than a pen. I miss the universality of files. The fact they can work anywhere, be moved around easily.
The file has been replaced with the platform, the service, the ecosystem. This is not to say that I’m proposing we lead an uprising against services. You can’t halt progress by clogging the internet pipes. I say this to mourn the loss of the innocence we had before capitalism inevitably invaded the internet.
(c) https://onezero.medium.com/the-death-of-the-computer-file-doc-43cb028c0506
Using the data types, slowly, through pain and suffering, we can indeed construct an expression...
(с) https://markkarpov.com/tutorial/th.html
The reason PostgreSQL is so flexible is actually quite interesting in a historical sense too. Many years ago, one of the most well-known PostgreSQL developers, Jan Wieck, who had written countless patches back in its early days, came up with the idea of using TCL as the server-side programming language. The trouble was simple--nobody wanted to use TCL and nobody wanted to have this stuff in the database engine. The solution to the problem was to make the language interface so flexible that basically any language can be integrated with PostgreSQL easily. Then, the CREATE LANGUAGE clause was born...

(c) Hans-Jürgen Schönig, Mastering PostgreSQL 11
Here's the question: how much does all this pedantic hiding, annotating, and making sure you don't double-cross yourself by using a "for internal use only" method actually improve your software?

...

Even if they're secured with the private incantation, nothing is stopping you from editing the file, deleting that word, and going for it. And if this is your own code that you're doing this with, then this scenario is teetering on the brink of madness.

What all of these fine-grained controls have done is to put the focus on software engineering in the small. The satisfaction of building so many tiny, faux-secure fortresses by getting publics and protecteds in the right places and adding immutability keywords before every parameter and local variable. But you've still got a sea of modules and classes and is anything actually simpler or more reliable because some methods are behind the private firewall?

(с) https://prog21.dadgum.com/206.html
Is that the intent of the hardcore interview process? To find people who are pure programming athletes, who amaze passersby with non-recursive quicksorts written on a subway platform whiteboard, and aren't distracted by non-coding thoughts? It's kinda cool in a way--that level of training is impressive--but I'm unconvinced that such a technically homogeneous team is the way to go.
(с) https://prog21.dadgum.com/208.html
I’ve met full professors who, in a rational world, would fail an interview for apprentice dog-catcher. I’ve met fewer, but still a significant amount, who in an ideal world I would be allowed to punch very hard in the face. Idiots, sexual predators, functional imbeciles and smug, awful, petty miserable people.

...without the need for anyone to be a sociopath, there’s a center to this problem which is just cultural and doesn’t require anyone to be committed to Broadmoor — it’s that academic researchers are often old people with job security who exclusively employ young people who just happen to be crucially reliant on them, and who have little job security.

No sociopathy required, just normal people with a LOT of power.

...

No good deed goes unpunished, and your decision to try to improve the world and devote your life to your innate human curiosity and the betterment of humanity is odds-on to turn out horribly. We picked a fairly miserable point in history to do this.

Good luck. It sucks, but it’s the only science we got.

(c) https://medium.com/age-of-awareness/12-thing-you-should-know-before-you-start-a-phd-9c064a979e8
Every time you use unsafePerformIO, a kitten dies.

(c) Michael Snoyman
Holy creeping boilerplate batman!

(c) Michael Snoyman
PHP is an awful, obsolete language, patched again and again to make it more modern. It's like wearing an old leather jacket that has been patched repeatedly, yet it still has a nasty smell. This is entirely subjective of course and I'll take old and trustworthy technologies technologies any day of the week. Except PHP isn't trustworthy and it never was.

I have never seen a high level language plagued with so many security issues and this extends to apps built in PHP, like Wordpress. You could attribute that to sloppy coding, or to its popularity, yet if you take the top web vulnerabilities in the wild, most of them (like SQL injections, or remote code executions, or stupid bugs related to implicit conversions, session tampering, etc) aren't possible with modern libraries built in static languages, or at least very hard to accomplish by accident.

...

PHP is unsuitable basically for anything that's not querying MySQL and then spitting an HTML back, which means the learning curve will be worse, because you've picked a very limited hammer.

(с) https://news.ycombinator.com/item?id=21566546 comments
Примечение по терминологии. В тексте иногда используется понятие "просранная задача". Это - технический термин, который лишён оскорбительной коннотации и обозначает просранную задачу.

(c) https://github.com/ClickHouse/ClickHouse/blob/master/docs/ru/extended_roadmap.md, найдено https://news.1rj.ru/str/oleg_log/2375
Look for feedback. Ask for feedback. Beg for feedback. Show your APIs to your peers, and collect all the feedback you get. Try to momentarily forget how much work it would be to implement the requested changes. When receiving negative feedback, trust the principle that all feedback is useful. Any opinion (e.g., “This whole thing sucks”, from Joe Blow) is a new piece of information, which you can recast into a fact and add to your mental list of facts (e.g., “Joe Blow, a Linux fanatic, strongly dislikes this COM-inspired architecture”). The more facts you possess, the better the chances that you will design a good API.

(с) The Little Manual of API Design, Jasmin Blanchette
If you’ve used JavaScript, you might have seen its with statement. It’s widely regarded as a design mistake, and it was removed from the language in ES5 strict mode. Well, you’ll be pleased to learn that with makes a reappearance in the Nix expression language! Whether this is also a mistake is up to you.
(c) https://medium.com/@MrJamesFisher/nix-by-example-a0063a1a4c55
Earley parsers are among the most general parsers out there. They can parse any context free language without restriction, and can even be extended towards context sensitivity. They are reasonably fast on most practical grammars, and are easy to implement.

On the other hand, most of the information I found about them is encoded in cryptic academese. Deciphering it is hard for non-experts (it was certainly hard for me).

(c) http://loup-vaillant.fr/tutorials/earley-parsing/