Most of the discussions about AI applied to coding end up having someone who states that it's just not worth it (at least the moment) and someone else who then chimes in to say that they mostly use it for "boilerplate" code.
I have trouble understanding the "boilerplate" thing because avoiding writing boilerplate is
1) already a solved "problem" long before AI
2) is it really a "problem"?
The first point:
* If you find yourself writing the same piece of code over and over again in the same code it's the indication that you should abstract it away as a function / class / library.
* IDEs have had snippets / code completion for a long time to save you from writing the same pieces of code.
* Large piece of recycled functionalities are generally abstracted away in libraries of frameworks.
* Things like "writing similar static websites a million times" are the reason why solutions like WordPress exist: to take away the boilerplate part of writing websites. This of course applies to solutions / technologies / services that make "avoid writing boilerplate code" their core business
* The only type of real boilerplate that comes to my mind are things like "start a new React application" but that is a thing you do once per project and it's the reason why boostrappers exist so that you only really have to type "npx create-react-app my-app" once and the boilerplate part is taken care of.
The second point:
Some mundane refactoring / translations of pieces of code from one technology to the other can actually be automated by AI (I think it's what you're talking about here, but how often does one really do such tasks?), but... Do you really want to? Automate, it, I mean?
I mean, yes "let AI do the boring staff so that I can concentrate on the most interesting parts" make sense, but it's not something I want to do. Maybe it's because I'm aging, but I don't have it in me to be concentrated on demanding, difficult, tiring tasks 8 hour straight a day. It's not something that I can and it's also something that I don't want to.
I much prefer alternating hard stuff that require 100% of my attention with lighter tasks that I can do while listening to a podcast and steam off in order to rest by brain before going back to a harder task.
Honestly I don't think anyone is supposed to be concentrated on demanding stuff all day long all week long. That's the recipe for a burnout.
Because we're all working at different companies on different codebases in different languages doing different things, we're all talking abstractly about something we think is the same, when really it isn't. Obvious to every programmer is to make a library if you're copy and pasting code multiple times,
but the overhead of that means you don't do that if you only do that once or twice. the problem, in humans, as with LLMs, is the context window. after running create-react-app or whatever, there are a number of steps to do that are repetitive, but because that doesn't happen often enough to fully automate it, you just do it manually. LLMs let you do that level of boilerplate without all the overhead of manually configuring snippets in the IDE.
Hm, no, it sucks. "I can do that with ease because I've done it so many times" is really a terrible argument to explain why something is good. If you've lost a leg, walking with a crutch becomes second nature to you, but that doesn't mean that's the preferred or most efficient way of walking for the human being.
Yes, you know by heart that all_of requires "foo.begin()" and "foo.end()" and the capture context "[]", but it doesn't negate the fact that many other, better languages, just know how to cycle an array without having to specify begin and end, know how to capture arguments when needed, don't require a useless (in this context) return, nor clutter a single line of code with nine differenct gibberish symbols like "(", ")", "::", ",", "[]", ";" "{", "}".
Take the ultra humble javascript: foo.every(a => a % 2)
When you need three times the characters to obtain the same result, and those charcters are a clusterfuck, it is not relevant if years of usage made you comfortable nonetheless with it.
Not to take away from your other criticisms, but in most languages how the arguments are captured has no relevance (in Javascript — and most every other managed language — the environment is always captured by reference and the GC handles lifetimes of "whatever"), whereas it is very relevant and important for C++. So I think that part of the criticism is unwarranted.
Though Rust didn't go to the same lengths[0] you still have to specify whether the environment is captured by reference (the default) or by value (`move` lambdas), because that can have a large and semantic impact on the system.
This. If you read the comments here seems like I've been stuck in analysis paralisis because I didn't use Redux, Webpack, Clojurescript, Ember. Guess what? Maybe I should investigate those four, right? This surely solves the problem. /s
I find C# to be better, but things are ok everywhere as long as they're kept easy. I think that function (param?: Array) is simply better than function (param) because the IDE can hint you that the function accepts a single parameter, that it is optional and warns you if you try to pass a string because it must be an Array.
Maybe this now sounds mundane, but I also uninstalled Firefox and not because of gay activism, corporate identities, political influences. I uninstalled it because it's become a bloated, slow as fuck software. Everytime I'm working on Chrome and I have to fire Firefox up to test a site, I insult it for all the time it takes to start up.
If something doesn't work, I open up the console and I'm impressed by how unusable it is. Maybe I've been spoiled by WebKit's one, but I find it a pain to work with Firefox.
The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument is true.
Sure, you can overdesign in any language, but some inner language characteristics of Java lead to it more than other languages do.
Copying input to output is a statement, if you think about it in in a logical, human way: "I want you, program, to perform the action of copying this to that". But Java, unlike some other languages forces you to say: "Make a class, make a main function because YOU need it, Java, and only after please do what I really want and copy that input to the outout".
In python, for instance, I'm in control of whether making a StreamCopier class, a copy_stream() function or just get to the core of what i want and write "print(input())".
Generally speaking, in most dynamic languages if I want to access the to_string() method of something passed to a function, I can pass a list, an int, a Duck object and till it has a to_string() function I'm good to go, or I can even monkey patch to_string() and call it a day.
In (too) many cases Java the language forces you to make instances over instances and implementation of interfaces and the like just to access the data you need in the way a framework or a method wants, not you, and often this is frustating because you see your data "just there" and the language fights against you preventing you to acccess it in an easy way. I need to call to_string() of SomeClass but I have an instance of SlightlyDifferentClassStream? Good luck with that, maybe the only possible way is to create a DifferentClassConverterProxy just to have a DifferentClassTranslator, extend TraslatorStream, feed it with my SlightlyDifferentClassStream and have something compatible with SomeClass.
This is not only true to Java, some of these "problems" arise from it being a statically typed pure OO language (a very good thing on my book when it is not implemented in a dumb way) that is put to shame by a cleaner implementation of the same principles like the one seen in C# that, on top of all, also offers a powerful dynamic programming, lambdas and so on.
Also, Java suffers from an enterprisey background. I consider a language environment to be a very relevant part of a language itself, and Java has promoted the proliferation of ridiculous bahamut frameworks with a freaking large number of classes and instances "just in the case someone needs to extend it".
These are facts, not "Har-har-so-many-classes".
Take a sane implementation of a web framework like Django. It is an opensource project born from the needs of a small group of developers. You don't have "so many classes" if you only write those that you really need to solve of your problems, and the project progresses from there to embrace the everyday, real world needs of a larger group of contributors.
Most Java frameworks I've worked with really give me the tangible perception of a large group of monkey developers programming them following line by line a technical specification bible of thousands of pages written by a council of architects with business people yelling at them "mooooore, mooooore, we need more of all of this so that we can sell to ANYONE!"
