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

Sorry, these claims are just not true. AI generations in these categories are impressive on release, but blatantly generic, recognizable, predictable and boring after I have seen about 100 or so. Also, if you want to put them to use to replace "real work" outside of the ordinary/pretrained, you hit limitations quickly.

The scaling laws of the Internet were clear from the start.


Your example is a better search engine. The AI hype however is the promise that it will be smarter (not just more knowledgeable) than humans and replace all jobs.

And it isn't on the way there. Just today, a leading state of the art model, that supposedly passed all the most difficult math entry exams and whatever they "benchmark", reasoned with the assumption of "60 days in January". It would simply assume that and draw conclusions, as if that were normal. It also wasn't able to corrrectly fill out all possible scores in a two player game with four moves and three rules, that I made up. It would get them wrong over and over.


It's not a better search engine, it's qualitatively different to search. An LLM compose its answers based on what you ask it. Search returns pre-existing texts to you.


If search was only about finding existing texts, LLMs would be qualitatively worse, as they frequently misquote or even invent non existing sources.


Was this written by a LLM?


> Once you get used to Lisp, you stop noticing the parentheses and rely on indentation instead.

Who does that? LISP has a datastructured syntax, textformat has no meaning in it.


Humans read code. I'd like to become a machine someday, but alas, I still am human and I need to read mine/others' code. Lisp code too.


Such interview processes are big red flags. The company can't afford taking a risk with you and at the same time tests how desperate you are by making you work for free. They are likely short on cash and short on experience. Expect crunch and bad management. Run.


So they ignore minutes entirely and just live in hours?


As I understand, they're less stressed about having things at precise points in time and are fine with waiting. I guess they would say something like "13 zero zero" when necessary...


Separation of concerns is the false promise of all these so-called "architecture patterns." Their advocates make you believe that their architecture will magically enable separation of concerns. They offer blunt knives to make rough slices, and these slices always fail at isolating relational concerns, inviting entirely new layers of complexity.

You had a relational database, designed to store and query a relationship between a user and their orders. Now, you have a user management service and an order service, each wrapping its own database. You had a query language. Now, you have two REST APIs. Instead of just dealing with relational problems, you now face external relation problems spread across your entire system. Suddenly, you introduce an event bus, opening the gates to chaos. All this resulting madness was originally sold to you with the words, "the services talk to each other."

Who ever claimed that REST services compose well? Because they can "talk to each other"? Really? Only completely disconnected architects could come up with such an idea. REST services don’t compose well at all. There aren’t even any formal composition rules. Instead, composing two REST services requires a ton of error-prone programming work. A REST service is the worst abstraction possible because it’s never abstract—it’s just an API to something extremely concrete. It doesn’t compose with anything.

Microservices aren’t micro. They’re hundreds of large factories, each containing just one small machine. Inputs need to be packaged and delivered between different factories in different locations, adding complexity every step of the way. This is what happens when enterprise architects "rediscover" programming—but from such a disconnected level that the smallest unit of composition becomes a REST API. Rather than solving problems, they create a far larger problem space in which they can "be useful," like debating whether a new microservice should be created for a given problem, and so on.

The same critique applies to "hexagonal architecture." In the end, with all of these patterns, you don’t get separation of concerns. The smallest unit of the architecture was supposed to be the isolation level where your typical problems could be addressed. But your problems are always distributed across many such units, making them harder to solve, not easier. It’s a scam. The truth is, separation of concerns is hard, and there’s no magical, one-size-fits-all tool to achieve it. It requires significant abstraction work on a specific, concrete problem to slice it into pieces that actually compose well in a useful and maintainable way.


Could as well have walked into a police station or uploaded the manifesto on his GitHub.


There is a multitude of governments involved in Bitcoin with different incentives and strategies. If you claim "The government can do X to Bitcoin" you should explain which government(s) and how exactly that would work. When was the FED a "democratically elected government", by the way?


Any nation's legislature, if threatened with loss of control of the nation's money, would immediately make it illegal to use any tender not sanctioned by that state. A vast amount of the state's historical policing was aimed largely at preventing alternative currencies from forming (consider, e.g., Isaac Newton's role at the Royal Mint).

They will put you in jail; withdraw your business licence and suspend your limited liability; deny your bankruptcy claims; tax you into oblivion; and so on. The state has every incentive to destroy a private currency, or a private army, or a private police force.

The only reasons states have take some interest in bitcoin and the like is that they aren't currencies. If there was any viable way of making ordinary daily economic transactions in BTC, it wouldnt exist. Inside the crypto system, "coins" are mere tokens with basically no ability to be traded for any goods or services. To buy anything you need to exist the system into an actual currency. So long as that latter step is required, BTC/etc. isnt a political project in the sense of this article.

"Money" isn't much more than a veil over the good-and-services of a society, an approximate quantitative measure of their marginal value. Governments require control over the money supply to manage this activity (eg., in pandemics) so they can, eg., prevent a widespread economic depression by temporarily exploiting inefficiencies the gap between the notional-and-actual value of money, giving people lots of it. Woe betide anyone who sells cars in BTC when there's a war on; you'll be in prision as a traitor.


One merely needs to look at US history to see that this is incorrect, before the Federal Reserve existed there were several competing bank "currencies" backed by gold that were commonly used instead of gold because they were easier to exchange, but with the knowledge that they could be traded for gold if needed.


> The state has every incentive to destroy a private currency, or a private army, or a private police force.

I don't see how currency is similar to an army or police force, could you elaborate?


The supply of money is one of the main means a government has to conduct economic policy. Consider what would have happened during the financial crash if governments hadnt been able to inject massive amounts of it into the economy.

Libertarians assume that if there's no democratic control over the currency, somehow, Reality, will make everything turn out ok. Well we tried that for a very long time, and it was a disaster. Every crisis is much worse if you cannot control the money supply.

In any case, no modern state would ever give this up. Its vital for their being able to deliver policies that people want, and to managing times of crisis.


It's also vital to undermine the savings of the population, which has been the case in most countries (perhaps less noticeable when there is a working financial system, but in many other countries people don't have access to invest in the market, or don't trust the institutions).


Cars were sold/bought for BTC and ETH when the war came to central Ukraine, nobody went to prison for that. Many people there do transactions daily via TRON chain nowadays.


I was thinking more of a major car company, rather than a few individuals making transactions. Two people can trade on any basis; you can trade a car for baseball card if you like. Nevertheless, the only story I can find in this case is one long-time crypto enthusiast selling a car with BTC, which happens everywhere from time to time.

My point was that during any major event in which the state requires control over the money supply, people making any meaningful difference to that control, won't be free to do so. In order to conduct a modern war, all states need to place large parts of their economies on a war-footing and requisition industries for defence (eg., iirc, 40% of the UA economy is now on defence).

Since BTC isnt a currency, trading with it has little impact on any state; it might as well be old bottles of wine. If it were to ever gain this status, and companies during a war were meaningfully offering their services in it, that would severly interfere with a state's ability to operate.

This just won't happen. It's absurd even to imagine it. If the libertarian problem with the state is how it uses its overwhelming legal, political, social etc. power to mismanage and economy and force people into capital controls etc... it's the dumbest thing in the world to suppose that by having people install a database, you've somehow undermined the state's ability to act.


Do they have a realistic shot at implementing immutable datastructures?


Oh for sure. That's not the tough part. :)

jank uses immer for that: https://github.com/arximboldi/immer


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: