misja111

It is not always a good idea not to argue, even given all the points that the author has made. If you have a meeting, and someone proposes something: if you don't speak up, it means you agreed to it.

Let's say you're discussing the next release and someone brings up some disastrous idea. You know he won't listen so you decide to keep quiet. The release comes, things blow up as expected.

Don't be surprised if you find your manager at your desk a bit later asking you to work late shifts to fix it. After all you are all in the same team, and you didn't speak up when the plan was discussed.

So in a meeting, speak up and don't give in if you are sure you are right. I have learned this lesson the hard way.

As someone who has had shoulder issues for the last 25 years or so, including partial tendon tears, I can tell you that even if your tendon would have been damaged, the treatment would have been strange. With moderately damaged tendons, you want:

1. stop any inflammation, by taking NSAIDs for a few days

2. detect and correct any behavioral patterns that could have caused the presumed overwear of the tendon

2. start physiotherapy to strengthen those muscles that can take over the load from the damaged tendon

These are not quick fixes, because quick fixes don't exist here. Stuff like shockwave treatment, massages etc will only lessen the problems for a few hours at most, after which they will come back.

I'd say that in cooler countries, warm water could be very useful, e.g. for heating houses.

This is exactly what made it so difficult. It is much easier to have a feature like this from year 1 than to add it to a language that has grown and evolved for 18 years already.

But isn't PECTT already challenged by quantum algorithms such as Shor and Grover?

AI is like a junior developer. You have to review her code carefully but she is most definitely useful.

Who says you have to bet against them? In Polymarket you can choose either side of a bet.

Why didn't they include assembly? IMO this should be the benchmark, not C

This kind of article keeps coming back, I've seen similar articles on LinkedIn where the bottom line is to switch from Python to C. The reasoning, in a nutshell, is that if a language allows you to waste fewer CPU cycles, it is more energy efficient, hence greener.

This completely ignores the fact that such a language might be more difficult to master because it uses fewer higher abstractions; CPU efficient languages tend to be closer to the machine domain and further away from the mathematical and real world. So while in theory the language lets you write very efficient code, you might well miss the opportunity and it could even be that using some off the shelve abstraction in a higher level language, your code would have been more efficient.

To drive that point to the extreme: the ultimate CPU efficient language is the language of the CPU itself: assembly. Try writing an efficient highly scalable webserver in assembly alone, good luck with that.

Then there is something else that all these articles conveniently ignore: development speed. Most of us write software for commercial enterprises. Product owners want the new feature tomorrow, not next year. They don't want a clever and amazingly fast application that might crash in production, they don't want security holes by missed buffer overflows.

Also, most of us work in a team where colleagues come and go, including yourself. Your colleagues won't be happy with you when you leave them some amazingly cleverly and efficiently written software that nobody understands or can maintain.

TL;DR; while all else being equal, the point of the article is true: it has little to no meaning in the real world. Yet, with phrasing like 'green languages', 'reduce the carbon footprint', these articles will catch on to an uninformed audience again and again.

Whenever I'm in an interview (almost) like this, I happily remind myself that interviews work in two directions: they are also for me to evaluate my possible employer.

Yep, Claude is behaving more and more like a human being.

To me, the real question after reading this, is: Is your new implementation of Azure’s RSL now being used?

If it is, and it works well, then to me this is far more meaningful than the fact that AI wrote 130K lines of code.

It's not about traceability, it's about not having to use the dollar as currency.

exactly! This should have been part of the prompt. If you choose not to do this then you shouldn't be surprised about the high token usage.

There are several cases where this is not possible or desirable:

- you are using AI as an E2E testing tool and it's a requirement to not just test the API but also the workings of the UI

- you are using some third party tool and want to automate its usage

> Every function is a specification that the compiler can verify against its implementation.

This has been tried so many times already. It works nice for functions that only do some arithmetic. But in any real life system that pushes data around over the network or to databases, most things will happen inside effects which leaves the compiler clueless as to whether the function implementation does what it's supposed to do or not.

Don't get me wrong, I'm a big fan of using the compiler to improve productivity and I also believe strong typing leverages LLM power. But this kind of function specification is a dead end IMO.

The root cause of some of the bugs seems to be the opaque nature of some of the Unix API. E.g.

> The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0.

To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data, you have this get_user_by_name function, and then it goes and starts loading shared libraries. This smells like mixing of concerns to me. I'd say, either split getting the user data and loading any shared libraries in two separate functions, or somehow make it clear in the function name what it is doing.

I have been doing this for years already after finding out by myself that it worked. Staring at anything works, even staring at your screen as long as you make sure you focus out.

> How do you think engineers in the second half got there? By writing tons and tons of code to "build those reps" and gain that experience.

Well this is true, but that doesn't mean that there isn't any other way to acquire this knowledge. Until now, this way of gaining deeper understanding was simply the most practical one, since you needed to write lots of code when starting out as a software engineer.

But it's just as well possible to gain knowledge about useful abstractions and clean code by using AI to do the work. You'll find out after a while which codebases get you stuck and which code abstractions leverage your AI because it needs fewer tokens to read and extend your codebase.

Is 4.6 without adaptive thinking better than 4.5? Honest question. I switched back to 4.5 because 4.6 seemed mostly to take longer and consume more tokens, without noticeable improvement in the end result.

Well the fix is simple, just use 4.6 or even 4.5

I'm actually seeing a similar thing when comparing 4.6 and 4.5. It burns a lot more tokens, does show more how it is thinking along the way, but I don't see a strong difference in the end result. Occasionally 4.6 even seems to get stuck in its 'processing' phase, while 4.5 doesn't on the same task.

I disagree. Much of what makes software complex for us, makes it complex for LLM just as well. E.g:

- a very large codebase

- a codebase which is not modularized into cohesive parts

- niche languages or frameworks

- overly 'clever' code

I'm playing backgammon. Not just online, but live tournaments as well.

What I like about it: it's one of those games that are easy to learn but difficult to master. Modern analyzing tools can detect your errors and weaknesses, providing you with eternal possibilities to improve.

But also, I like the excitement of the live tournaments, which like poker, have money prizes and an entry fee. They are all over the world and I especially like visiting tournaments in places which I otherwise wouldn't visit. Plus after a while you'll make friends in the tournament circuit, so it becomes a social thing as well.

Where did you get those points from? Do you have a source? The 10 points I've read in the media are different, e.g. https://www.thenationalnews.com/news/us/2026/04/08/what-is-i...

I was replying to OP who sketched the scenario

> Worst outcome is the US attacks Cuba ..

As you probably know POTUS was announcing already that Cuba would be next.

> If this happens and Cuba decides to launch drones/missiles against the US homeland, it's not an exaggeration to say that Cuba is flattened and invaded that same afternoon.

Yes that would be a typical US solution. Let's liberate the Cuban people! By flattening them.

Can anybody explain how these plug-in solar panels work? I am suprised that it's possible to just plug them in to your wall socket.

For instance, isn't it complicated to have their output be in perfect sync with the frequency that comes in via the electricity net? Because to me it seems that if they won't, you will have lower benefits or even a net minus after plugging it in.

It depends. If all I want is some prototype or pet code project, my LLM can write most by itself. The speedup could be 10 times or more. However, if I'd let a LLM write code for my work, I'd have to very thoroughly review it and most likely ask it to rewrite it several times. Each time this would require a new review of course. There would still be a speed up but I guess at most somewhere around 25%.

In practice I try to combine the best of both worlds. I write some code by myself and rely on my LLM for parts that are not too big and where I expect it to do a pretty good job.

I can't imagine he's building anything serious. How can you claim otherwise that your agents were deploying code that you couldn't verify. Imagine doing that in any serious business ..