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.
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.
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.
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.