With operator overloading you can provide same numeric operation interface to library types such as big integers. Sure, you can also define methods and make sure your primitive types also define those methods but now you have some confusions (like equals vs == in Java).
> going forward with knowledge specialization becoming unnecessary and eventually unfeasible due to the triviality of AI making it not needed for a human being to study a hyper-niche subject
Did your philospophy degree not teach you to think "what could go wrong?".
But there's nice stuff under performance and security.
Ctrl+F gemini returns only 2.
@dang change this clickbait headline. original title is "
Android 17 is here". I suggest "Android 17 is here - Android Developers Blog" since its a dev focused post.
There's no manufacturing sector to employ them if you displace them from agriculture. They'd be displaced into gig economy. This would just increase the population of a handful of metropolitan cities which are already congested. India should fix its cities first.
Yeah; I have a minimal vimrc with cursorline, wrap, line number, some other option to make arrow keys jump to next line from end. I set a different colorscheme on each machine when I have to deal with multiple machines. That's it.
Present iteration of LLMs are, despite what normies would believe, aren't optimised to provide correct solutions. They are optimized to __sound smart__.
This may be just an undesirable artifact of the RLHF process. But the end result is same. They try (?) too hard to sound smart.
Last generation LLM writing was too obvious in its soulless journalistic nature. But the current generation LLMs do all the following things to appear smart; From the lowest levels to highest level
- use clever writing styles and punchlines. Not X, it's a Y'ed Z. (Though it's not funny and makes no sense).
- Overstuff the technical terms, most often using a +. "Add a shim + iptables rule + signal handler".
- Over engineer the low level design. (Eg rather write a function to do some complex parsing when a way exists to avoid it altogether. Write tricky bash script and parse the output for what could be achieved by stdlib in few more lines).
- over engineer the code flow: this is rather because they're clueless and can't step back. But I have fun seeing the LLM come up with 4 5 levels of branching and then extract it into a function, whereas a human would step back and try to avoid the branching.
- over engineer the high level design: well your mistake is letting the word soup machine lead the design. It will add all and kitchen sink with need bullet points and + marks. Only a pleb not sufficiently educated in the matters of computer science will be impressed with such Markdown kitchen sink designs. It's fine to rely on LLM for brainstorming and discovering how to do A, B and C. But if you outsource the job of design, it's instincts (!) to sound maximally smart using bullet lists and + marks will kick in.
Or you know, you can architect around testability from the beginning, where multiple branches / instances of same application can run in the same cluster - in different namespaces.
I am fine with them training on my open source code (which is pretty bad but not the point, because they're providing the service for free). I will be super pissed if I pay for enterprise and they train on it though. I believe this is the opinion of majority programmers.