Hacker News new | past | comments | ask | show | jobs | submit | varenc's comments login

Aren’t we just continually moving up layers of abstractions? Most of the increasingly small group doesn’t concern itself with voltages, manually setting jumpers, hand-rolling assembly for performance-critical code, cache line alignment, raw disk sector manipulation, etc.

I agree it’s worthwhile to understand things more deeply but developers slowly moving up layers of abstractions seems like it’s been a long term trend.


We certainly need abstractions for the first layer of the hardware. An abstraction of the abstraction can be useful if the first abstraction is very bad or very crude. But we are now at an abstraction of an abstraction x 8 or so. It's starting to get a bit over the top.

I disgree with your sentiment. One thing that is constant in my experience as a computer programmer, there are always "old" computer programmers complaining that there are too many abstractions.

You cannot see any way in which we run out of possible abstraction layers? I think in the past we have assumed that was natural language, but I think natural language is a pretty poor programming language. What people actually want when they say that, is for someone to read all the nuance out of their mind and codify it.

I don't think we actually have been abstracting new layers over the past day 5-10 years anyway. Most of what I see is moving sideways, not up the stack. Covering more breadth not height or depth, of abstractions.


    > Most of what I see is moving sideways, not up the stack. Covering more breadth not height or depth, of abstractions.
I don't follow your logic. This comment is so vague. Do you have a specific example?

There are not many languages that for example abstract higher than C# and compile down to it. And whilst we are building abstractions in C# (etc) those are one step up (height), and then there are many of those frameworks, thus many steps sideways (breadth)

We only run out of abstraction once there is stagnation and time to really bake.

As long as some new thing is being invented in our industry, a new abstraction will be needed because the old one just can’t quite flex enough while being backwards compatible.


One problem is that we're building abstractions on top of older abstractions when that isn't most efficient. Suppose we write an HTTP server that can call CGI programs. Then we implement PHP as a CGI program. Then we write a Lua interpreter in PHP. Then we write our website in Lua.

Some of those levels are useful. Some of them are redundant. We should embed a Lua interpreter in our webserver and delete two levels of abstraction.

(I'm not aware of any actual Lua interpreter written in PHP, but it's representative of the kinds of stacks that do exist out there)


Only really relevant if the efficiency is valuable but yeah totally. It’s not just about new abstractions on top of the stack but also new abstractions that replace the middle and bottom of the stacks.

Do any mainstream streaming services offer you greater than 1080p on desktop Linux? I had thought that none of them allow it due to the perception of weaker DRM. And because 90% of consumers watching on desktop really care/notice

I can't say I care that much: 1080p quality pixels are really good, I'd prefer that to messy 4k with visible blocking artifacts.

This is moot for El Salvador. They’ve been dollarized since 2001 and USD is effectively the only legal tender.

That is helpful context— it's too bad TFA wasn't a bit more clear on the history.

In any event, you could still make the case that prior to this bitcoin experiment, the people and economy of El Salvador still were benefiting from a human hand on the monetary tiller, it's just it was that of the US Fed rather than their own officials (elected or otherwise).


Agreed. `tee` without any flags is essentially a no-op and doesn’t have much use, whereas teemoji does. This feels more like `nl` in the sense that it outputs its STDIN with something prepended. But with the additional support for splitting the stream, in which case its STDOUT is unmodified like tee.

I still absolutely love this project. It’s inspired me to play around with CoreML.


++ to this rec.

I've tried Stats over the years as the project has evolved and I keep coming back to iStat Menus. Stats feels very inspired by iStats Menus's design as well. The one thing I appreciate about Stats though is support more SMC sensor values.


The CLETS database LACSD used includes non-conviction records, investigative records, gang affiliations, and other data that aren’t part of the proper background check process. For example, if you were arrested but never charged, or if you’re a known gang member without any convictions, those records would be in CLETS but not in the system they’re legally supposed to use for concealed carry permits (CCPs).

State law doesn’t allow this kind of non-conviction information to be used in CCP decisions, so this was an overreach. (previously you had to be of "good moral character" and have "good cause" to get a CCP, but these have been replaced with objective criteria)

You could argue that having more information might lead to better decisions on who gets a permit, but that’s not what the law allows—and letting police pull extra data whenever they feel like it creates obvious risks of abuse.


From the article:

> The Wiz Research team immediately and responsibly disclosed the issue to DeepSeek, which promptly secured the exposure.

Assuming everything mentioned in the article was fixed before publication, I don’t see an issue with it.


Yeah my bad I missed that and edited OP.


The vulnerable services were presumably fixed by the time this was published. I don't see anything wrong with releasing the details now.


Looks like LaTeX syntax.


LaTeX would be \(H_{2}O\) – or, more likely, \ce{H2O} or \ch{H2O}.


You definitely still need data centers to train the models that you’ll run locally. Also if we achieve AGI you can bet it won’t be available to run locally at first.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: