misja111

I expect the TSLA stock to jump another 20% based on this

Lol I guess this is our future, we have to prove that we are not bots. How would I prove this to you?

Lol, I have 42 years of experience in coding, of which 29 paid. I learned to program when I was 14 years old, studied computer science and went to work in IT. I'm 56 years old now and working as a tech lead.

Being a craftsman is a deeply human desire that AI is destroying, not sure if this is a fun future to look forward to.

AI is giving me back the feeling I had when I first learned to program, when I was 14. At 14, I suddenly had a tool in my hands that was like an extension of my imagination. I could create tools, games and what not with it, this is what I loved. AI is that same tool on steroids. If what you like is creating things, AI lets you do it at 10 times the speed.

I feel the opposite, AI is making me less tired at the end of a working day even though I get much more done.

What used to tire me: being forced to have a sharp eye for syntax errors when programming, or simply the effort of all the typing and navigating through source files. Trying to visualize details of the codebase I was changing, while at the same time keeping a high level picture in my head of the feature I was changing.

With AI, I can focus on the high level picture. I can focus on the steps to get there and the steps to verify that it works. I don't have to focus on syntax anymore and there is much less need to visualize large parts of my code base. With AI, work is still tiring but much less, and in a different way.

The RPKI fix is that any node in a rpki tree is signed by the certificate from the authority above it, all the way up until some root certificate that you trust. So you cannot have some party hijacking a prefix, it would not be signed by its parent authority.

What’s the argument for OpenAI being so inherently critical and interweaved with the rest of the economy that it can’t be allowed to fail?

AI companies are more and more interweaved with the economy because half the world is owning their stocks or has lent them money. Or, they have invested in companies that in turn have invested in AI. It is very similar to the situation before the credit crisis.

Nowadays the main point of PR's is to find out what Claude has been coding for me.

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