skysight-inc/HackerNews huggingface dataset:
A local variable is often worse: Now I suffer both the noise of the unabstracted thing, and an extra assignment. While part of the goal is to give a reasonable logical name to the complex business logic, the other value is to hide the business logic for readers who truly don't care (which is most of them).

The names could be better and more expressive, sure, but they could also be function calls themselves or long and difficult to read names, as an example:

if (
x.is_enabled ||
x.new_is_enabled ||
(x.in_us_timezone && is_daytime()) ||
x.experimental_feature_mode_for_testing
)...

That's somewhat realistic for cases where the abstraction is covering for business logic. Now if you're lucky you can abstract that away entirely to something like an injected feature or binary flag (but then you're actually doing what I'm suggesting, just with extra ceremony), but sometimes you can't for various reasons, and the same concept applies.

In fact I'd actually strongly disagree with you and say that doing what I'm suggesting is even more important if the example is larger and more complicated. That's not an excuse to not have tests or not maintain your code well, but if your argument is functionally "we cannot write abstractions because I can't trust that functions do what they say they do", that's not a problem with abstractions, that's a problem with the codebase.

I'm arguing that keeping the complexity of any given stanza of code low is important to long-term maintainability, and I think this is true because it invites a bunch of really good questions and naturally pushes back on some increases in complexity: if `is_enabled(x)` is the current state of things, there's a natural question asked, and inherent pushback to changing that to `is_enabled(x, y)`. That's good. Whereas its much easier for natural development of the god-function to result in 17 local variables with complex interrelations that are difficult to parse out and track.

My experience says that identifying, removing, and naming assumptions is vastly easier when any given function is small and tightly scoped and the abstractions you use to do so also naturally discourage other folks who develop on the same codebase from adding unnecessary complexity.

And I'll reiterate: my goal, at least, when dealing with abstraction isn't to focus on duplication, but on clarity. It's worthwhile to introduce an abstraction even for code used once if it improves clarity. It may not be worthwhile to introduce an abstraction for something used many times if those things aren't inherently related. That creates unnecessary coupling that you either undo or hack around later.
The Euclidian group in four dimensions is a fourth dimension, but the Lorentz/Poincare group is the fourth dimension. ;)
I've seen a book promoting the idea that methods should not be longer than 5 lines.

Of course now I know these ridiculous statements are from people hardly wrote any code in their lives, but if I'd read them at 18 I would have been totally misled.
Whichever parts of the world that may be, you can guarantee that it happens anyways.

Unenforceable rules are never followed.
Pages Are a Good Idea
As for complexity and gigantism:

https://openhub.net/p/qt5
(8,876,034 lines of code)

https://openhub.net/p/gtk
(1,031,203 lines of code)

https://openhub.net/p/fltk
(467,564 lines of code)
James Webb's Big Year for Cosmology – Universe Today
I'm also a fan of linting everything. Custom linter rules ftw.

This and documenting non-lintable standards so that people are on the same page ("we do controllers like this").

This is how I like to build and run my teams. This makes juniors so much more confident because they can ship stuff from the get go without going through a lengthy nitpicky brutal review process. And more senior devs need to actually look at code and business rules rather than nitpicking silly shit.
Agree. Another item here that is contextual: what is the cost of a bug? Does it cost millions, do we find that out immediately, or does it take months? Or does it not really matter, and when we’ll find the big it will be cheap? The OP joining a new company might not have the context that existing employees have about why we’re being cautious/clear about what we’re changing as opposed to smuggling in refactors in the same PR as a feature change.

I’m going to be the guy that is asking for a refactor to be in a separate commit/PR from the feature and clearly marked.

It doesn’t justify everything else he mentioned (especially the comments piece) but once you get used to this it doesn’t need to extend timelines.
It's interesting when talking about the focus on supply chain safety that they've decided to only recommend core-js. From my perspective, it feels like core-js is the top candidate for the next left-pad / colors.js type author induced ecosystem failure given the author's past attitudes and financial issues.
In the superlative, yes. It's a fairly new phrase, and hardly in my parlance, but it's growing on me when I'm in informal typed chat contexts.
As a p.v. (with storage) and BEV owner I still wait for OEMs start to build something FOR renewables, like bi-directional domestic charging stations since we have finally the very late relevant standard https://www.iso.org/fr/standard/77845.html and in the end it's just about signalling between the car BMS and the p.v. hybrid/battery inverter, batteries are 400V for 99% of both current real world.

I still wait for ALL APPLIANCE ease of integration with something even simple as ModBUS or MQTT instead of sealed boxes or useless cloud-services etc.

Because yes: that's the new deal, for those who know and want to embrace it, not for those who dream smart cities full of slaves powered by some large p.v. field. ALL of them failed, all distributed solution currently work.
I only did mushrooms twice in the 70s and I had a long tail of flashbacks and feel I had disturbed mental state for some considerable time.

It's wrong to go from the particular to the general but I cannot but believe in neuroplasticity after my own experience.

That said, if I had end-of-life anxiety I probably would think about the mushroom assisted "acceptance" thing, with due care and attention.
I think the 'Layered Architecture' section is all over the place.

There are a lot of terms thrown around with pretty loose definitions - in this article and others. I had to look up "layered architecture" to see what other people wrote about it, and it looks like an anti-pattern to me:

In a four-layered architecture, the layers are typically divided into:
Presentation
Application
Domain
Infrastructure

These layers are arranged in a hierarchical order, where each layer provides services to the layer above it and uses services from the layer below it, and each layer is responsible for handling specific tasks and has limited communication with the other layers. [1]

It looks like an anti-pattern to be because, as described, each layer depends on the one below it. It looks like how you'd define the "dependency non-inversion" principle. Domain depends on Infrastructure? A BankBalance is going to depend on MySQL? Even if you put the DB behind an interface, the direction of dependencies is still wrong: BankBalace->IDatabase.

Back to TFA:

> In the end, we gave it all up in favour of the good old dependency inversion principle.

OK. DIP is terrific.

> No port/adapter terms to learn

There is a big overlap between ports/adapters, hexagonal, and DIP:

Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. [2]

That is, the Domain ("application") is at the bottom of the dependency graph, so that the Infrastructure {Programs, Tests, Scripts} can depend upon it.

> If you think that such layering will allow you to quickly replace a database or other dependencies, you're mistaken.

Layering will not help - it will hinder, as I described above. But you should be able to quickly replace any dependency you like, which is what DIP/PortsAdapters/Hexagonal gives you.

> Changing the storage causes lots of problems, and believe us, having some abstractions for the data access layer is the least of your worries. At best, abstractions can save somewhat 10% of your migration time (if any)

I iterate on my application code without spinning up a particular database. Same with my unit tests. Well worth it.

[1] https://bitloops.com/docs/bitloops-language/learning/softwar...
[2] https://alistair.cockburn.us/hexagonal-architecture/
How to Become a 37 Year Old Broke Loser by RobertElderSoftware [video]
> From a performance perspective, as long as the hardware designer kept 32 in mind, it can schedule 32 lanes and duplicate the signals to the 16 or 8 wide lanes with no loss of performance.

I was looking at the things that were said for XE2 in Lunar Lake and it appears that the slides suggest that they had special handling to emulate SIMD32 using SIMD16 in hardware, so you might be right.

> So this is a situation where wider lanes actually need more hardware to run at full speed and not having it causes a penalty. I see your point here, but I will note that you can add that criss-cross hardware for 32-wide operations while still having 16-wide be your default.

To go from SIMD8 to SIMD16, Intel halved the number of units while making them double the width. They could have done that again to avoid the need for additional hardware.

I have not seen the Xe2 instruction set to have any hints about how they are doing these operations in their hardware. I am going to leave it at that since I have spent far too much time analyzing the technical marketing for a GPU architecture that I am not likely to use. No matter how well they made it, it just was not scaled up enough to make it interesting to me as a developer that owns a RTX 3090 Ti. I only looked into it as much as I did since I am excited to see Intel moving forward here. That said, if they launched a 48GB variant, I would buy it in a heartbeat and start writing code to run on it.
I read Hunchback of Notre Dame around 20 years ago. The ending is until today the only book ever to make me cry. Don't remember much else, probably a good time to pick it up again.
I don't think this is a good idea. You should be grateful that you have a job. There's no guarantee that you will be able to get another one after taking a year off. I say this as someone who has been unemployed for over seven months, and is struggling to pay bills, and buy Christmas presents.
If it was "only" [1] a viral disease, it should dissapear even without antibiotics after a week or two. So perhaps your body solved the problem alone, while you took antibiotics that had no effect.

This is a real posibility and is a real problem to test how useful the medicines are. So all serious studies use a control group [2] to compare the rate of spontanous healing with the rate of healing with the antibiotic.

[1] Some virus are very nasty and can kill you. People confuse the common cold andd the flu, but usualy the flu is much worse.

[2] Preferabely a preregistered double blind randomized control group, becuse there are a lot of other problem that can cause a false result.
Since we're insinuating, I bet you that Ruby is not their chief bottleneck. You won't get much more RPS if you wait on an SQL query or RPC/HTTP API call.

In my experience when you have a bottleneck in the actual Ruby code (not speaking about n+1s or heavy SQL queries or other IO), the code itself is written in such a way that it would be slow in whichever language. Again, in my experience this involves lots of (oft unnecessary) allocations and slow data transformations.

Usually this is preceded by a slow heavy SQL query. You fix the query and get a speed-up of 0.8 rps to 40 rps, add a TODO entry "the following code needs to be refactored" but you already ran out of estimation and mark the issue as resolved. Couple of months later the optimization allowed the resultset to grow and the new bottleneck is memory use and the speed of the naive algorithm and lack of appropriate data structures in the data transformation step... Again in the same code you diligently TODOed... Tell me how this is Ruby's fault.

Another example is one of the 'Oh we'll just introduce Redis-backed cache to finally make use of shared caching and alleviate the DB bottleneck'. Implementation and validation took weeks. Finally all tests are green. The test suite runs for half an hour longer. Issue was traced to latency to the Redis server and starvation due to locking between parallel workers. The task was quietly shelved afterwards without ever hitting production or being mentioned again in a prime example of learned helplessness. If only we had used an actual real programming language and not Ruby, we would not be hitting this issue (/s)

I wish most performance problems would be solved by just using a """fast language"""...
I love what you're saying. But, I've met a lot of people who have say 10-20 years experience designing applications with unnecessary and sometimes incredible cognitive load. There are serious incentives to NOT write "simple" code, let me share a few of them.

Root causes from my perspective look like:
1. Job security type development. Fearful/insecure developers make serious puzzle boxes. "Oh yea wait until they fire me and see how much they need me, I'm the only one who can do this."

2. Working in a vacuum/black hole developers. Red flags are phrases like "snark I could have done this" when working together on a feature with them. Yes, that is exactly the point, and I even hope the junior comes in after and can build off of it too.

3. Mixing work with play "I read this blog post about category theory and found this great way to conceptualize my code through various abstractions that actually deter from runtime performance but sound really cool when we talk about it at lunch".

4. Clout/resume/ego chasing "I want to say something smart at stand up, a conference, or at a future job, so other people know they are not on my level and cannot touch my code or achieve my quality."

Some other red flags. They alone maintain their "pet" projects for everything serious until they couldn't. Minor problems/changes come up, someone else goes in and fixes it. Something serious happens it's a stop the world garbage collection for that developer and they are the only one who can fix it disrupting any other operations they were part of.
> In most developed countries doctors are already parsimonious with antibiotics and generally won’t prescribe them unless an infection is observable.

Antibiotics as 'consolation prizes' is definitely a thing.
Sad that the article is not talking about bacteriophages[1]. Basically viruses that infect other bacteria. The world is full of them (and even virophages: viruses that infect other viruses). The soviet union started experimenting them, and they seem to be used to treat hard-to-cure infections like Staphylococcus aureus, but I guess it died down somehow?

[1]: https://en.wikipedia.org/wiki/Bacteriophage
> robotic litter boxes

Has successfully guilotined several cats.
The way I normally approach this is one big pr for context and then break it into lots of small ones for review.
World Famous Permaculture Property Tour, Holmgren and Dennett's Melliodora [video]
Not really. Adding oxygen for sure won't help. Also halon is stored in extinguishers as a pressurized liquid, not gas.
Wouldn't you agree that the problem is not the managers who hired and misunderstood their contributions, but the society who forged them and incentivised them to behave and think like that?

You can basically choose a "scape-goat" at any of these levels, or just choose to accept them all as equal parts of a strange contraption.
> some company that isn't giving you all the wildly expensive benefits you think you're entitled to

nice strawman
Electronics Test Gear on the Cheap
That's also true, though in this case I'm not necessarily worried about commonalities, just changing the way it reads to focus on the higher level ideas making up the large function.

But revisiting code after a time, either just because you slept on it or you've written more adjacent code, is almost always worth some time to try and improve the readability of the code (so long as you don't sacrifice performance unnecessarily).
It's a bit a joke, but not too much: the next step will be full integration with editor's undo/redo mechanism, which in the end could be seen as a log-based storage. Because that's the trend I've seen on the (little) new ideas from the VCS world.
This poster has +2551 karma. Stay classy HN.
there is huge incentive for people who don't know how to code/create/do-stuff to slow things down like this b/c it allows them many years of runway at the company.

they are almost always cloaked in virtue signals.

almost every established company you join will already have had this process going for a long time.

doing stuff successfully at such a company is dangerous to the hierarchy and incurs an immune response to shut down or ostracize the doing-of-stuff successfully so the only way to survive or climb is to do stuff unsuccessfully (so they look good)
Most new antibiotics come from soil bacteria. We got all the low hanging fruits, now you need to dig through tons of soil to find something new., Better culture methods would make it easier to run experiments instead of relying on genome rather than relying on /cloning/expression in E. coli.
You seem to be describing a company where bureaucracy is a feature not a bug.

Been there. Left, live thousands times better.
All of the bits that do make up secular christmas, do have pagan origins, which is more or less my point.

My general take is that every major religion has some sort of solstice related celebration.
Reuters: "Russia is using bitcoin in foreign trade, finance minister says"

https://www.reuters.com/markets/currencies/russia-is-using-b...

Your definition of "useless" must be different from mine.
There's at least one reason that something like this is going to be exceedingly rare in practice, which is that (usually) functions return things.

In certain cases in C++ or C you might use in/out params, but those are less necessary these days, and in most other languages you can just return stuff from your functions.

So in almost every case, f1 will have computed some intermediate value useful to f2, and so on and so forth. And these intermediate values will be arguments to the later functions. I've basically never encountered a situation where I can't do that.

Edit: and as psychoslave mentions, the arguments themselves can be hidden with fluent syntax or by abstracting a-f out to a struct and a fluent api or `self`/`this` reference.

Cases where you only use some of the parameters in each sub-function are the most challenging to cleanly abstract, but are also the most useful because they help to make complex spaghetti control-flow easier to follow.
I think this is a good point. If you learn a language and it's useful, you usually use it for many, many years. So long as the daily driving experience is great, onboarding doesn't have to be that important of a metric.
Saw someone on Mastodon I think comment that Interstellar was basically the same premise as the odyssey
Discussions

(6 points, 12 days ago, 6 comments) https://news.ycombinator.com/item?id=42407415

(16 points, 5 days ago, 6 comments) https://news.ycombinator.com/item?id=42477317
> F* is oriented toward verified, effectful functional programming for real-world software, while Lean is geared toward interactive theorem proving and formalizing mathematical theories, though both support dependent types and can serve as general-purpose functional languages in principle.
> Just because TSMC is getting the newest nodes first does not mean they have a monopoly in the semiconductor market.

Sure. Market research also places them as having somewhere around 65% of worldwide foundry sales [0], with Samsung coming in second place with about 12% (mostly first-party production). Fact is that nobody else comes close to providing real competition for TSMC, so they can charge whatever prices they want, whether you're talking about the 3nm node or the 10nm node.

[0] https://www.counterpointresearch.com/insights/global-semicon...

Rounding out the top five... SMIC (6%) is out of the question unless you're based in China due to various sanctions, UMC (5%) mainly sell decade+-old processes (22nm and larger), and Global Foundries explicitly has abandoned keeping up with the latest technologies.

If you exclude the various Chinese foundries and subtract off Samsung's first-party development, TSMC's share of available foundry capacity for third-party contracts likely grows to 70% or more. At what point do you consider this to be a monopoly? Microsoft Windows has about 72% of desktop OS share.
Why does pressing "go to defn" blank your short term memory in a way that code scrolling beyond the top of the screen doesn't?
debugging and error messages are still hard to deal with. Also, flakes should become standard at this point. Documentation on how to load modules and explore modules using nix repl is also lacking and/or frustrating. It definitely has rough edges. I do hope it will improve.
>And this makes it obvious why you should use a unique username everywhere!

Actually I was disappointed by the post, I was hoping it will be able to find the same person regardless of the username through analyzing the writing style, what they are talking about, the timezone etc.

The username doesn't prove anything, anybody can take any username anywhere. If someone targets you, they can take usernames on platforms you haven't claimed your username yet and pretend being you and damage your reputation.
Truck dealers push back on electric sales mandates in New Jersey
Polybius's Anacyclosis
> I don't use Snap on my Ubuntu Desktop systems because I don't like apps secretly updating without my awareness

My experience with Snap is that it bugs me about Firefox updates multiple times a day for two weeks. Okay, it does then update automatically and break the running program, but I can't claim to be unaware.

Apt is the thing that updates packages completely without my awareness, with Unattended Upgrades. Mostly it works, but I have to blacklist NVidia utilities, as they need to be in sync with the driver in use.
Is there a danger that with more sophisticated antibiotics, we could eventually eradicate too much good bacteria?
Now add different phosphor decays on the black parts for each subpixel!
Yeah it's kind of a weird narrative. Writing complex code is leaps and bounds easier than writing simple code. Often takes both experience and intelligence to see the correct way.
This is assuming that things break all the time, I've been using Ubuntu / Debian for the last 20 years I never had to re-install it because something broke.

Nowdays Linux is very stable, you can have things that don't work properly but you won't need a full re-install.
It works fine. Not all the methods need to use all the struct members.
Rethinking Zoning to Increase Affordable Housing
Wow. That's 3M lbs of water. (1.34M kg)
More so retailers are externalizing loss insurance out to the consumer instead of treating as part of the price.

Assuming they’re able to discriminate on the cost to bias against high theft regions you’ll see a lot more pressure locally to fix the problems.
Using online services require so much special attention it starts to weight up to the benefits given. Considering the risks, it is already in pair with the value delivered.
More sophisticated, I'd expect more precision not just more of the same (and bad) old.

Now we just wreck havoc of absolutely anything which is a bacteria, it would be nice to be able to select the typology.
This typically can be coded with something like

def foo(...) = Something.new(...).f1.f2.f7

Note that ellipsis here are actual syntax in something like Ruby, other languages might not be as terse and convinient, but the fluent pattern can be implemented basically everywhere (ok maybe not cobol)