Why haven't they broken out yet, I wonder, if they're more efficient for inference and LLM costs are now weighted towards inference over training?

I'm still waiting for something that can learn and adapt itself to new tasks as well as humans can, and something that can reason symbolically about novel domains as well as we can. I've seen about enough from LLMs, and I agree with the critique that som type of breakthrough neuro-symbolic reasoning architecture will be needed. The article is right about one thing: in that moment AI will overtake us suddenly! But I doubt we will make linear progress toward that goal. It could happen in one year, five, ten, fifty, or never. In 2023 I was deeply concerned about being made obsolete by AI, but now I sleep pretty soundly knowing the status quo will more or less continue until Judgment Day, which I can't influence anyway.

This must be a bad attempt at a joke, right? Darcula is a nice theme (I personally prefer high contrast), but surely IntelliJ’s code inspection and automatic refactoring have always been its claim to fame.

https://en.wikipedia.org/wiki/Minus_World

> With internal REST for companies I have seen so many single page specific endpoints. Gross.

As someone pointed out in reply to another comment, GraphQL is "a technological solution to an organizational problem." If that problem manifests as abuse of REST endpoints, you can disguise it with GraphQL, until one day you find out your API calls are slow for more obscure, harder to debug reasons.

May I ask how you dealt with this? Were you able to explain it to Amazon support and get some of these charges forgiven? Also, how would you recommend monitoring for this type of issue with Lambda?

Btw, this reminds me a lot of one of my own early career screw-ups, where I had a batch job uploading images that was set up with unlimited retries. It failed halfway through, and the unlimited retries caused it to upload the same three images 100,000 times each. We emailed Cloudinary, the image CDN we were using, and they graciously forgave the costs we had incurred for my mistake.

You are being deliberately obtuse. Other comments in this thread offer correct examples of using PDO to avoid SQL injection. I didn’t mean it was impossible to write safe database code using the standard library—obviously, PHP is a Turing-complete language, it can be done!—I just meant it’s awkward, and verbose, and developers are unlikely to do it consistently throughout an application. Hence this type of concern is best abstracted into a library.

To your point about “indicting a language,” most languages have footguns like this. The worst you can say about PHP is that the documentation should do more to discourage new users from working with PDO directly. (And I mean the official documentation—the language maintainers can’t be held responsible for the kind of unofficial tutorials the article complains about.) But regardless of what the official docs say, most PHP development today is done using frameworks like Laravel, Symfony, and Zend framework that do not suffer from SQL injection issues.

Comments URL: https://news.ycombinator.com/item?id=25751782

Points: 1

# Comments: 0

I was surprised to hear this. Is this still true for Vue 3?

Also the Laravel framework for PHP has the most Github stars of any server-side framework: https://twitter.com/denicmarko/status/1309714816290951168

If they don't have access, then the tools ought to be standardized to the point where they can be integrated into any editor. The Language Server Protocol[1] seems like a step toward this.

> I'm of the opinion that code should be written independent of the tools used to understand and modify that code.

This a widespread, "common sense" opinion that I've come to disagree with strongly. No one would argue that, e.g., illustrators, 3D modelers, music producers, etc. should be so tool-agnostic—and yet their situation is quite similar. One could produce a complex piece of music in Audacity instead of using Logic or Ableton, but musicians don't have the same mentality of picking the cheapest, most austere, or lowest-common-denominator tool. Instead, they invest in tools that enhance their productivity. And that's precisely what's at stake here. Pairing (a) a language that allows implicit "smart" features like type inference with (b) an equally smart editor to make what is implicit in the code explicit to the developer as needed, is more productive than forcing the developer to make everything explicit themselves.

Re: using VIM over ssh, your choice of scenario is revealing. Why would you limit your everyday development work based on the lowest common denominator tool you're forced to use in an emergency? Also, it's not necessary to run code inspection on the remote box. JetBrains IDEs, for example, will copy a folder from ssh or a similar environment, index and inspect them locally, and then sync them back as needed.

1: https://microsoft.github.io/language-server-protocol/

Using PhpStorm, I've worked with 100 kloc PHP codebases where almost every type was inspectable. And the language support and tooling are only getting better all the time.

1: https://stitcher.io/blog/new-in-php-8

2: https://www.php.net/manual/en/migration71.new-features.php

3: https://stitcher.io/blog/typed-properties-in-php-74

4: https://phpstan.org/blog/generics-in-php-using-phpdocs

5: https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psal...

With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime