skysight-inc/HackerNews huggingface dataset:
> There is a secondary rule to the DRY "rule of three": If I can blow it away and rewrite it so easily, there is nothing to reuse or refactor in it.

This rule seems not to be correct though. For example it would mean that one of the most common and widely accepted (as far as I know, and admittedly I know nothing) changes—replacing an explicit for or while loop with some kind of iterator construct, for example a foreach or even a call to a map function—was a bad idea. By and large most individual for loops are pretty easy to understand and rewrite if you look at them. The first problem is that naturally one hardly ever has to read just a single for loop, and that the impact of small insults to abstraction and readability really adds up when repeated tens to thousands of times in a codebase. Second: that a piece of code is easy to read, blow away and rewite is very far from a guarantee of no bugs in either the old or the new version, and AFAIK the history of the vanilla for loop is a classic example of that. Again the impact of this depends on the fact that the for loop can be repeated many times in a codebase.

OTOH the example code in TFA was not repeated with (or without) small variations many times in the program. (I'm not talking about how often it was called or about repetition inside the example code here, ofc.) So your test probably does correctly show that changing or not changing this piece of code on its own is only a small-stakes decision, unlike having say 500 vanilla for loops in the program. But if you consistently let individual bodgy code segments pass then surely you're liable to end up with a large and diverse body of them in the codebase, and that's in some ways even worse than 500 for loops, which can at least all be found with a simple search.
I have been interested in finding BSD users who are interested in https://nixos.org/nix/ or even a NixOS/kBSD. It solves all these problems and in my view is the continuation of the spirit of the port system.

(The problem with bundling isn't disk space, but composition. Individual applications can compose fine, but libraries can't if they link other libraries at different versions, and use those library's types (ABI) in their own interface (ABI). To solve this problem you need to distinguish between public vs private dependencies in your package manager.)
Summarized List of Resources on Negotiating
https://twitter.com/dchest/status/1215751501567709185
This is a corner case, though, and one that is itself a code smell (i.e. in well-written code, it should be very rare). Having implicit null references, and implicit null checks on dereference, optimized for rare a corner case to the detriment of safety in typical code patterns, is a bad thing.

And it definitely is a significant source of errors in managed memory languages, from my experience in C# and Python. It can also be pretty tricky to track down, when the code producing the null happens to run long before the code dereferencing it.
Cambridge Analytica claimed that they had deleted the data they collected.
No, I noticed the error while walking out of the DMV and went back in line to have it corrected. The physical card never left the premises!
The OP is using clean as a language figure. He attacks the idea of clean code but not as the hygiene of the writing but as in removing what he thought to be unnecessary repetitiveness only to later come to the conclusion that it was adequate yet somehow repetitive.

Why repetition is the opposite of cleaneness in the first place?

What he calls here clean code (and dirty code) is modelling that piece of software with or without repetition and not legibility (which would be a more reasonable opposite concept of "clean code").

He reflects on one thing right tho, the idea that he jumped into abstractions too soon, hence he refactored removing repetitions but injecting a model that was inadequately modelling what was needed in the project in the first place. And worst, he did that without discussing design in advance with any colleague first (that was the biggest mistake IMHO) loosing time and efforts for all involved parts.

So the real underlying issue was that code repetition blinded him of design priorities. Nothing to do with the ability to do abstractions and write clean code on top those abstractions. If you do clean code in the wrong abstractions cleanness (or its opposite) will be irrelevant.

But a huge problem is that he again (with his article itself), jumps too soon into the wrong conclusions: attacking the skill to do abstractions and the skill to write clean code. Readers will be induced to confuse the real thing for the language figures he is forcing with that text.

The skill of imagining good abstractions for general concepts and writting well are things that go way beyond writing software code (all professions needs these), hence attacking them makes no sense at all and a successful attack on them would only promote some degree of general confusion (including areas beyond those directly affecting the professional career).

Back to the anecdote, what would have been good?

1. Prioritize where you want the flexibility and power of the design first and care about luxury details like "code repetition" later.

2. Discuss with colleagues in advance (specially those who will review your merge requests) to agree on what's to be done and what's going to change.

3. Actually implement the changes and open MR.

PS: in favor of the OP, he was generous in sharing his experience so others can learn from it.
What stops Google from suspending a paid account, assuming they issue a pro-rated refund for anything paid in advance?
I work for one of the largest health care networks in the northeast US. Nearly all of our PACS use the default installer password - which in at least two cases is literally just the name of the company that makes it.
Checkout Super Graph it's a GraphQL to SQL compiler and API service in GO. In production mode it uses prepared statments so no compiling hence very latency. https://github.com/dosco/super-graph
TL;DR: Falcon 9's Block 5 booster core B1046 would be "destroyed in Dragon fire".[0]

[0] https://twitter.com/elonmusk/status/1216148780635938816
I wouldn't say nix isn't anti-centralization, I'd say it's policy-agnostic. At the end of the day, not everything composes, only things whose interface is in some way compatible.

Traditional package manager conflate having something with composing something (everything is ambiantly available and interacting). Nix separates those, so you can have every version of everything, and only try to compose things that fit.
A program that takes an integer n and outputs the n'th digit of the number it represents is a finite representation of an infinite stream of digits.
They always did. Young people like to be contrarian.
> I think the benefits of saving disk space by sharing libraries do not justify the inconveniences we, desktop BSD and Linux users, obtain from being forced to disrupt and upgrade hundreds of installed software packages, just because one single desired upgrade requires to pull its dependencies

It's funny, from your point of view having a centralized repository with a (usually) single (usually) latest version of a library is a bad thing that may be (and probably isn't) justified by the goal of saving space.

From my point of view having a centralized repository with a (usually) single (usually) latest version of a library is an awesome thing that I would leave any other ecosystem to get, and the space savings is just a bonus that doesn't much matter.

Most dependency maintainers don't provide updates for more than a few versions of their software. When one piece of software depends on -latest and another piece of software depends on -legacy, you can ship both with the central repository model. In the Linux distributions I've used this is a solved problem. Arch Linux has five different versions of the JRE that are separately installable.
But like op is asking. Is there an example of desertification from unsustainable agriculture? Seems kind of unbelievable to me too.

In fact I’d do some unsustainable agriculture on my sidewalk to stop weeds from growing.
AppStream does not allow installation of multiple versions of the same app AFAIK. I believe this is what they refer to in the clumsy sentence "The one disadvantage of Application Streams from SCLs is that no two streams can be installed at the same time in to the same userspace. However, in our experience, this is not a common use case and is better served using containerization or virtualization to provide a second userspace." in the linked article in the sibling comment.
Stoicism has enjoyed a revival of late
Meaning Verilog and VHDL?

Rust gets a lot of attention here on HN, and the percentage growth in number of (non-production) coders, relative to any previous period, is high, but the absolute numbers are still very, very tiny, whoever you count.

If we count new production coders, any growing, established language is adding enormously more. C++, Javascript, maybe C#. The most surprising of these is C++, because it should already have penetrated everywhere it was viable, but paid conference attendance doesn't lie.

And, yes, Verilog etc. are probably adding quite a lot more than a year ago, again relatively.
To use Lyft, or to sign up? Using alternate payment methods makes sense once you sign up. I do it, too. But can you start a new account without a credit card?
Every time I have seen a feature that was written general to handle possible future uses, after a year of sitting unused there will certainly be modifications or surrounding code that doesn't support the planned extensibility. So it can never be used without a lot of work changing things anyway.
The theory is that the US has committed to ruining things for everyone if bad things happen to them. Otherwise, hostile countries would have an incentive to create false flag attacks, or to incite an enemy to attack in truth. But if Iran knows that North Korea nuking DC means that they get nuked too (along with essentially everyone else on the planet), there's less incentive to make it happen.

Same goes for Russia/China - wouldn't either of them 'love' a world where the US got in a nuclear exchange with the other? No more competition!
As somebody who makes films himself this isn’t quite as easy: although I personally agree with your sentiment, the task of a story you told in the filmic medium usually isn’t to be realistic. What studios instead care about is to create a world that most people can believe in.

And sometimes this means to make something look futuristic just to constantly remind viewers that this is a completely different universe.

Additionally set designers have usually quite little time to think about all the details. They are essentially in the job of cobbling together something that looks ok in as little time as possible for as little money as possible.

When it comes to interfaces in films I kinda like the way Alien (1979) did it: very realistic, kinda gritty, very distinct graphical language
> Yes, people do exactly that. It's part of running a "rolling" distro

And we do that too—for OpenBSD -current. But we have neither the manpower nor the interest to do such work for old releases.
> I could even sue someone who would ban me for this.

That only works for a very small subset of the world population. Even in the US, try sueing tictok.
Ask HN: Good Books as an Introduction to Economics?
For context, I’m someone who has very sparse knowledge regarding economics. I was hoping to find a good introduction to economics that I can read. Any thoughts?
You raise a good point because as we’ve found in the 1930’s and I believe finally performed in the 50’s, alchemy can occur. (Seaborg with a particle accelerator). The method of discovery is performed by trial and error and building off the mistakes and successes of your predecessors and Newtown was just the first step in many of his discoveries.
My advise is rather simple: start consulting startup candidates based on your extensive experience.

You are basically helping them avoid the hurdles you came across through your 11+ years of professional experience and you are pretty much giving them a number of steps ahead of other startups that have to go through trial and error until they make it, if they are lucky that is.

Try to write down the standard, cliched if you will, steps a startup needs to go through until they become functional and autonomous from a technological point of view.

I'm sure through this consulting experience you will be narrowing down countless of unique niche projects that could be offered as SaaS or even PaaS by you that could boost a startup's momentum AND help you make good money while doing two things you seem to love the most.

Now, as far as concern analysis paralysis, you can solve this by doing simple, standard writing; school-like if you will.

Dedicate a notebook, the good ol' pen and paper thing (lol), and write down each idea of yours by separating its pros and cons.

Concentrate on each project separately without letting your thoughts or worries intervene and narrow down each project's unique features until you feel pleased by what you have written up until the very end of it.

If you can, apply the logic of Normalization Form until you exhaust all potential commonalities each step has with its previous ancestor.

Doing so can reveal so many things to you, even help you extract common factors from each project separately and combine them to produce yet another project or idea that could lead to something interesting, let alone profitable if it gets the right attention and response from users.

I cannot think of anything else right now, but if you want to keep in touch to philosophize it a bit further, feel free to contact me via my email which is included in my profile.

Take your time to rest your busy mind and let me tell you something you need to hear: you got this mate, don't worry about it.

The less you worry, the less you pay attention to your mental noise, the clearer everything will become around you.

Keep it up mate!

Cheers.
>What track record?

Tech company. Automation. Advertising.

Do they need to be skinning puppies or something?
> Duplicated code causes many issues. You mentioned introducing bugs, but it also makes the code harder to read

That is I believe contestable. Yes, it can end up easier to read but there is a big tradeoff - when you remove code from its context it is much harder for a reader to reason about it. Once something is extracted into a function you can't see, you have to mentally ask the questions like "could this return null / None?", "how will it behave if the input is negative?", "does it throw exceptions", "is it thread safe?" etc etc. All this is directly observable in context when the code is inline, not so when it is removed to a central place.
I updated my router to this release today. Then I setup:

1. DNS over HTTPS to cloudflare so that my DNS doesn't leak.

2. Hurricane Electric's tunnelbroker, so that I can access the IPv6 web.

3. Dynamic DNS so that I can address my home connection anywhere, even if my IP changes.

4. Wiregaurd so that I can access everything on my home network.

I tend to agree that most people should just buy Ubiquiti SOHO gear and be done with it, but at least for me, this is cheaper and a bit more fun.
This! Our company OpenSUSE Tumbleweeds were still vulnerable on Friday. On Arch, the package was already available for two days then.

The thing is, the distro maintainers need to decide whether they want a fast moving "latest and greatest" approach, which might break stuff by accident, or go a "slow but always dependable" route, which you can depend on as company, with painful losses if things go south (in which case there should be an express lane for important security fixes).
J.D. Vance Launches $125M Fund in America's Heartland with Thiel and Andreessen
The org chart shown in the article is old by 2 years and seems like an oddly selected on for that time. A current org chart would shown a different split between men and women.
Yes. Thank you! From my experience multi-repo doesn’t make problems go away, it just defers them and introduces others. I’m not against multi-repo or a strong proponent of monorepos... each have their strengths and drawbacks and there is a time and place for either. I struggle to deal with folks who firmly lie in one camp or the other.
11 years sober here. I think my experience mirrors yours, especially how peoples' questions about OUR lack of alcohol are masking their own insecurities about THEIR alcohol consumption. Spending most of my adult life in two alcohol-heavy communities (the military and Japan), I see it all the time, but I try not to throw it back in their faces.
> What is so special in using other providers? Is it just... normal?

It's probably not normal. I've heard of Google, but not Fastmail, Matomo, Nextcloud, Collabra, Plex, Jellyfin, F-Droid, Aurora, Lineage, PinePhone, Simple Mobile Tools, Hover, Matrix, PocketCasts, AntennaPod, or "Ting".
Last time I tried Takeout, to backup an account I was about to delete, they demanded a phone number to "confirm mu identity". No, thank you.

I configured NeoMutt to grab the e-mais (the only thing I had on it) and that's it.
There are clearly targeted phishing attempts, I wouldn’t rule it out.

Edit: I should add, I was very surprised when I got a phishing email sent by the obviously compromised email account of a colleague, and when I emailed them to say their email was hacked, the person who hacked them replied telling me everything was OK, and to open the attachment.
Thanks for the link. Best as I can tell from the ClojureScript, this is in reference to a refactoring that would cross layer boundaries. Like taking the methods

findItems(db)
findWidgets(db)

and refactoring to

findAnything(db, items_tablename)
findAnything(db, widgets_tablename)

So the repetition is good because it's a data access layer and you shouldn't know the storage details, not because repetition is always good.
The md5 weakness (that everyone talks about) is about collision resistance, which isn't relavent to password hashing.

Generally you want slow, high cpu & memory hash functions for password hashing. This is the opposite of what md5/sha/blake aim for, as they want to be fast as possible. A fast hash allows the attacker to make many guesses very quickly (i think you can get something like 2 billion sha256 hashes a second with high end gpus). A slow hash makes it harder for the attacker to take lots of guesses (adding high mem usage helps protect against using alternate architectures like fpgas to speed things up).

Anyways, for passwords use something like argon2.
A Chrome extension that collected shopping data from 17+ million people
The Bitcoin network can perform some 10^20 SHA-256 hashes per second. That’s one 11-character upper/lowercase alphanumeric password PER SECOND.

A practical password cracking rig can probably do upwards of 10^11 hashes per second. The same rig can only do 10^5 bcrypt hashes per second.
I disagree.

If they had separate classes for TextBlock and Rectangle, then likely there are separate requirements involved. It may have been that at the time they needed separate classes the requirements for resizeTopLeft was identical, but they are still two separate requirements.

I suggest everyone take a minicourse or read a book on systems engineering - at least the part where they discuss requirements. The fact that two distinct entities have an identical requirement for something does not mean there is one requirement. It means there are two requirements which (for now) happen to be identical.

The key phrase is happen to be. You do not apply DRY to separate requirements even if they are the same/similar.

Look at it from a testing perspective[1], which is similar to how a systems engineer will look at it. If you would write a separate test for it, it is a distinct requirement. (Actually, the ordering should be the opposite: If it is a separate requirement, it should have a separate test).

[1] And not from a TDD perspective!
What does HOT stand for? It’s surely not higher order types but I can’t think of anything beginning with homotopy.
> "Fuck" is a distasteful word for an act with near-universal approval.

Near-universal approval and near-universal distaste. A curious phenomenon, isn't it?
Show HN: Aoede Linux, an Arch Linux-Based Audio Distribution
Xinjiang Victim Database
Right so how does "Tech company. Automation. Advertising." become "Google has a track record of collecting data totally unrelated to its core business and using it to inform advertising."

If there's a track record of this, you can give other examples of how Google has done that, right? Where they've gone out and collected data under the guise of doing something benign and then used it for advertisements.
I didn't think hashing the hash would be helpful here, and couldn't think of a way to mitigate against this attack.

After reading more it seems the only mitigation is Layers of Security.

https://en.m.wikipedia.org/wiki/Pass_the_hash#Mitigations
The author not only fails to explain why his refactored code is worse he doesn't even show all of his code. There is simply not enough information to know whether the refactoring is better or worse. In terms of less lines of code and code reuse, it is better in this sense. I suspect the author is pretty junior himself to imply the old way is better than his refactoring without a clear explanation as to why. I guess putting your baseless opinion on a fancy blog or medium makes you seem more legit than you really are.

I get his point, however. In the spirit of his argument there is an exact answer as to why one way of designing a program is better than another way despite more/less code re-use or more/less lines of code. I'm not even going to get into legibility here as that is just an opinion piece. Also I'm going to give a very concrete answer here. No design principles no design philosophy or any of that.

Let's say you have feature which we call "A" that can be created as a composition of several primitives. We call these primitives "a, b, c, d." Let's also say feature "A" can be constructed from a different set of primitives "b, f, g, a."

Note the overlap in primitives. The overall set of primitives are different but both ways of constructing feature "A" can share the same primitives if needed. The two sets in the example share primitives "a" and "b".

Now let's say we want the code to be flexible enough to construct feature "B" or feature "C" sometime in the future.

lets say feature "B" needs primitives "a, d, b" to construct.

lets say feature "C" needs primitives "b, f, a." to construct.

Which method of constructing Feature "A" is better knowing that you will need to construct Feature "B" in the future? what if it was Feature "C" for the future?

Obviously depending on "how" flexible you want your design to be you can choose one way to initially construct the program or another way. It's all an opinion and anticipation for the way you design your program in the future.

One strategy to remove opinion from your design is to try to incorporate the full union of primitives "a,b,c,d,f,g" Or find another completely different set of primitives (perhaps "h, i, j") that can be used to construct features "A", "B", and "C."

SO the concrete answer is "h, i, j" is the best set of primitives you can use to construct your program but if "h, i, j" aren't available then your choice of "a, d, b" or "b, f, a" or "a,b,c,d,f,g" both hinges on whether you need to construct feature "B" or feature "C" in the future.

The problem with this article is that he never got into the nature of program design/organization. Just vague reasoning and hand wavy examples.
> Why repetition is the opposite of cleaneness in the first place?

It's an idiom after the book by Robert Martin, whose central theme sits around heavily refactoring code to remove repetition and in fact even non-repetitive code. The first few chapters hammer the concept that functions should be extremely short and aggressively refactored to compose them into subfunctions. It essentially coined the concept of "clean" code in these terms.