You're assuming that AI-based code is even that minimally good.
Here's a nice litmus test: Can your AI take your code and make it comply with accessibility guidelines?
That's a task that has relatively straightforward subtasks (make sure that labels are consistent on your widgets) yet is still painful (going through all of them to make sure they are correct is a nightmare). A great job to throw at an AI.
And, yet, throwing any of the current "AI" bots at that task would simply be laughable.
Wow, a blast from the past! 1996, what a year that was.
Sun was freaking out about Microsoft, and announced Java Beans as their vaporware "alternative" to ActiveX. JavaScript had just come onto the scene, then Netscape announced they were going to reimplement Navigator in Java, so they dove into the deep end and came up with IFC, which designed by NeXTStep programmers. A bunch of the original Java team left Sun and formed Marima, and developed the Castanet network push distribution system, and the Bongo user interface editor (like HyperCard for Java, calling the Java compiler incrementally to support dynamic script editing).
While I was working at Interval Research Corporation in 1996, after playing around with and reading over the source code and documentation, I wrote up a deep comparison and analysis of Internet Foundation Classes (IFC) versus Marimba Bongo (which was written by Arthur van Hoff, who worked on Java, wrote AWT, and before Java wrote another user interface system for NeWS similar to Bongo and HyperCard in PostScript, called HyperLook), and other related user interface component technologies.
>This is a comparison of two component frameworks for Java, IFC and Bongo.
>IFC (Internet Foundation Classes) is from NetScape, and is similar NeXTStep, which was written in Objective C. It was written by some former NeXT developers, whose company NetScape bought because they needed a Java toolkit.
>Bongo is from Marimba, and is similar to HyperLook, which was written in NeWS object oriented PostScript. Marimba was founded by some of the original Sun Java developers, who left Sun to form their own company.
[That also compares IFC with Microsoft's ActiveX/OLE/COM/MIDL stuff, and gets into some Java/JavaBeans/J++/CORBA/OpenDoc politics, and includes some comments by Arthur about IFC, AWT, Bongo, JDK 1.1, etc.]
Here's a later article I wrote about HyperLook (that article is still a work in progress, since I haven't finished the comparison to HyperCard and Bongo):
During 1996 I also wrote up a wide ranging survey of the interesting component, plug-in, user interface toolkit, and application framework technology at the time:
These are problems that we aren't trying to solve, and that a lot of other people are. We should try to take advantage of other peoples work, instead of re-inventing the wheel.
the component object framework problem (Open Doc, OLE, COM)
the distributed object problem (CORBA, Electric Communities)
the application framework problem (Galaxy, MFC)
the programming language problem (Java and other languages)
the multimedia library problem (ScriptX, QuickTime, DirectX)
the garbage collection problem (COM, Java, ScriptX)
the window system toolkit problem (HyperLook, Java AWT, MFC)
the development environment problem (Metrowerks, MSDEV, Visual Basic)
the web browser problem (NetScape, CyberDog, Explorer)
the database problem (DAO, ODBC, Oracle)
the image editor problem (Photoshop, Premier)
the multimedia 8 track tape player problem (Director)
the killer app problem (Lotus 123, SimCity)
the operating system problem (Windows 95, Netscape)
the pointless standard problem (VRML, COSE)
or any combination of the above (TCL/Tk, ScriptX, NetScape)
> the whole Java standard library will still take years to change to use them, if it ever does.
All Java collections (which are what really matters) are being retrofitted alongside with the introduction of value types. As soon as value types are introduced (and the HotSpot team is working hard on that right now), all collections will be fully value-ready.
> Go already gives better tools than Java for managing native memory through cgo, which is a far less painful interface than JNI
JNI is being replaced by Project Panama: http://openjdk.java.net/projects/panama/ (you can already use a similar FFI already with JNR, which serves as a blueprint for Panama's FFI: https://github.com/jnr I've used JNR to write a FUSE filesystem in Java without a line of C, and unlike JNA, it's fast!)
> From what I've heard, Azul has a great GC, but the throughput is extremely low.
Not at all. Just a little lower than with HotSpot's throughput collector, and possibly higher than with G1 (although G1 changes a lot, so that might not be true).
Python's dynamism is nice, but it's so damn inflexible, requiring my to follow the One True Way.
That can be good, and makes it easier to eliminate bad code in reviewing.
But it also means that you can fight with the interpreter to do what you want.
Scheme gives me both dynamism and flexibility, with less speed tradeoffs. Yay!
However, there was someone on my team obsessed with turning everything into a macro.
What's the point of first-class functions if you just macro everything?
Also, Scheme's stdlib is purposefully small, so you sometimes need to reinvent the wheel. Thankfully Scheme makes it both easy and pleasurable to do so.
The rundown is, though fast and dynamic, code review can be painful unless you follow standards, and you might run up against, "Oh... I need to build my own FTP library", though SLIB (depending on your circumstances), can eliminate some of that.
C's compiler feels like a breath of fresh air after that.
Unless you hit a runtime error, it makes writing code a breeze, quickly and efficiently.
Unfortunately, it doesn't protect you against yourself, or lazy people on the team trying to use void pointers for everything.
So code review can be harder, and catching edge case segmentation faults can be quite difficult.
Enter, Pony.
Pony deals with the same areas Rust does, but for reasons I won't go into, when both Rust and Pony were young, my team started using Pony for a few little things.
It has been... An experience.
Pony is very type safe, it is exception safe, and data race free, all enforced by the compiler.
Which sometimes means the compiler will sit there bashing your code for a full day before you realise that you weren't writing it safe enough, and you can't just tweak it, the whole thing needs to be rewritten.
Also, the Actor Model being central to everything can be quite annoying, when you just need to fit a couple extra functions in somewhere, but you aren't sure where's best.
However:
The compiler doesn't let you screw up.
What you do write can become massively concurrent fast programs, easily.
Pony also has some fairly good documents, for such a young language that really doesn't have the backing of Rust.
So...
I get frustrated with any language I am forced to deal with over time.
I wish Python had compile-time contracts, but there is mypy to ease the pain now.
I wish Scheme had a better stdlib, but it goes against the ethos. (See RSR6 community breakdown).
I wish C was safer, but it's lack of safety makes it easier to do things like JIT.
I wish Pony was more flexible, but it'll never let me point a shotgun at my own foot.
If I spend too long in any world... It's time for a breath of fresh air.
Let me try to answer it. I'm sure that I won't change your mind, but when I published Anvil (a similar library for Java) - I got lots of questions like yours.
- XMLs are not type safe, I can type any tag name in there, and I can set almost any value to my attributes - AAPT won't even notice (yes, Android Studio is much smarter these days, it may give a warning, but it won't be a compiler warning, so it won't be in your automated build logs. You will also miss it when using other text editor or IDE). I can put a view inside another view (not a viewgroup) - and it will pass as well. Since we waste CPU time on XMLs preprocessing - it would be nice if they also warned us about our errors at this stage, not crashes in runtime.
- The file hierarchy is terrible. All XMLs must be in the same folder, no nested folders. Having a large project makes you have dozens of XMLs on the same layer of hierarchy. Since we have OS with directories - it would be nice to use that feature like we use it for java packages.
- There are some styles, but they are too limited comparing to, say, CSS. If one ever tried LESS or SASS - he will love the mixing, variables, calculated expressions etc. It's fast to write, it's easy to read, it's reusable. You don't have to jump around multiple closely related files to tie it all together in your head. You have them in one place. Since XMLs are processed - it would be nice if I could write something like "android:background=darken(@color/mycolor, 30%)"
- There is some responsiveness, but it's too limited. If you have 3 nested views, and the topmost has margin in landscape and no margin in portrait - you have to have two (almost identical) files. Or three, if you want to use merge/include. In fact now they are all in different folders, despite they are very closely related!
- There is no way to merge with unique ids (child layout will have the duplicated ids when included twice).
- There is no mixins or macros. If I have layout with textview+button pairs - I will end up copying those two tags everywhere. If I have macros - I would write it once, and then would only type `<TextViewWithButton text="foo" buttonText="bar">` - that is supposed to be expaded into <TextView .../><Button ..../> with some texview and button attributes substituded to the given actual values.
Here's a nice litmus test: Can your AI take your code and make it comply with accessibility guidelines?
That's a task that has relatively straightforward subtasks (make sure that labels are consistent on your widgets) yet is still painful (going through all of them to make sure they are correct is a nightmare). A great job to throw at an AI.
And, yet, throwing any of the current "AI" bots at that task would simply be laughable.