It works well enough with plain Ruby and plain Javascript. It ported a Rails 7, Vue 2, vuetify 2, vuex app to Rails 8 (ok, easy, I did it myself at least once), Vue 3, Vuetify 4, Pinia. I had to visually check the SPA, of course.
That's expected (the index out of bound). You have an array, and maybe it grows, you read a number from input, you don't check it against the size of the array because you want to torture the language, use it to get the element at that index and... I'm sure that there is a surprisingly number of different designs of what it should happen and a number of designed ways to ensure that it doesn't happen. But a runtime error is expected.
yes, so are the NPEs - both are runtime errors indicating a bug in the code. NPE was a major source of irritation 20 years ago, but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source. And the culture has evolved.
> but what many people do not know is that debugging NPEs in Java is easier now - they carry more information about the source
Unfortunately, no, they don't. Not after your application has been running for a while; newer JVMs arbitrarily decide you don't need the stack trace anymore, and all you see in your logs is "NullPointerException" (unless you still have the logs from several weeks ago, just after the last JVM restart, which might still have the full stack trace). Older JVMs were better, since they always had the full stack trace; debugging NPEs was easier with them.
There are several ways to get hold of tech and of any other thing. Russia did not have access to the H-bomb too, until it was handed to them. Ideals or money are very effective.
I see no difference anymore. I used Windows because it worked and didn't break obvious things. Thats gone. I switched to Linux because the user experience is now better. Never expected that this switch happens because Windows gets worse...hoped everytime Linux gets better.
Nah Linux is clearly getting better, but perhaps Windows is getting worse faster than Linux is getting better. Easier to destroy than to create and all that.
The point is that it is hard to prove that that 5 days code will never break. In the eyes of a customer a feature ready in one morning and in production before evening is a truly great thing and they know that even before AIs developers were shipping a lot of bugs. Some of them were evident only weeks, months or even years after the commit that added them. A customer of mine got a few hours of downtime a few Saturdays ago because some code from 2021 did some potentially long operation in the threads serving requests instead of doing them in a background job.
So what can one do when they expect that you use an AI to speed up development and they manually check features before they are deployed? You develop with an AI, check that it works, deploy to preprod, let the customer do its tests, business as usual.
There are a lot of variables here. Small features I would say of course. Big features or the foundation of another app or codebase is a lot more risky. So it comes down to weighing the tradeoffs and risks.
Even with small features I would say there is some kind of "entropy tax" that AI is adding, but of course this is yet another tradeoff. If companies find value in iterating quickly and then having to throw everything away just to iterate quickly again, then sure. Some businesses are setup to do this. Others not so much. You can't afford to write critical software over and over again. It has to be done right and having that extra care for a few days is the best tradeoff in these scenarios.
The sort of things that a human developer can do better than an AI is telling a founder that it is a bad idea to use country flags to select UI languages because languages have names and don't have flags and somebody will be pissed off by having to select the flag of some other country, maybe one they don't like much. I've been doing this today for the nth time probably because crappy sites spoiled a lot of people. I provided plenty of examples (check the EU web site locale selector) but it's not settled yet. An AI won't put much of a fight and will soon comply. I will too, I advise, customers put money on the table. Their privilege.
The issue of critical software is not much different. The people with the money eventually decide how to spend them and what to prioritize.
I think human developers can architect and design better software, and a good developer will probably develop features better as well. The issue is that "better" here is not immediately obvious. It might take a few months to realize the "way" the code was written is causing problems. Some people might never even realize this and just assume that's how all software is, it just breaks down over time (which is obviously not true, lots of decade old software and languages exist).
But if the company is ok with rewriting their code every few months, then it makes no difference.
Sometimes it is handy when doing something like ASCII art or drawing ASCII diagrams. Imagine editing a much more complex variant of this
----
| AB |
----
Finally, Shift-INS pastes from clipboard on Linux. A keypress saved compared to Control Shift V in a terminal. However they don't paste from the same clipboard: one is the primary selection (middle click) the other is the actual clipboard. However when I Shift INS into this textarea on HN I paste something else so I don't really know the rule and I stop here.
I always use middle click, which is a hardware button below my touchpad and it is one more saved keypress.
reply