This fully depend on the goal of the people that setup the AI machine. If the goal is set to destruct a population, the AI machine could be very efficient at doing the job...
I think that the last time I used a composite video signal was about 10 years ago to playback the video from a camera recorder with a magnetic tape.
Having application maintaining there own libraries is more like an loosely workaround than a solution. Some libraries of one application could share information with others applications that maintain an other version of the libraries, resulting in a inflating code and complexity to support old formats or resulting on unsupported situations. The Linux way of packaging libraries require constant support from the application providers, but the advantage is a fast evolving ecosystem, small footprint, and stable operations.
I have to see an OS that can link any libraries for any language to any application. I known that the GObject introspection project dream to bring something close to that: http://helgo.net/simon/introsp... . AFAIK, Vala (a kind of C + GObject) is the most advanced experiment in that direction with automatic binding in a number of languages already functional: https://github.com/antono/vala... . But here the OS have very little to do as the hard part of the linking process is done by the GObject introspection library of each language. Please note that GObject is able to work so well precisely because the naming schema is well defined.
It's actually popular to introduce a few new languages each year and to write a lot of libraries for each languages that do almost the same job. At some point in the future, so many choices will make more problems than it solve, mainly because of the dilution of the efforts and lack of support where the community is too small. C has a big community for good reason, but C in not used for some projects for others good reasons. Some basic object programming features is probably the most obvious one, especially when observing that many C projects organize there code like objects if not directly using GObject or similar libraries. Given the today situation, I think that C could evolve in a cleaver way without making any harm.
I completely agree with the first half of your message.
Yes inheritance imply function pointer, a very used feature in C so I don't understand why you find it so crazy.
Yes new C features will be developed in a fork like in every project. Maybe one of the fork will be interesting enough to get accepted by a large part of the community and be merged into the standard. Actually a lot of projects have some basic construction that look like objects, but each is different. There is GObject, but it's still confined to a small subset of projects.
I think that highly optimized standard libraries is the key for high level programming for any language. In a ideal world all languages would use the same libraries and only the syntax would change, but actually, using a language that have libraries that support most of the needs for your application make a lot of sense. PHP for example was one of the early web server language that provided a library complete enough to make web server programming easy and this proved to be a hit, despite the fact that the language was still in a early stage and evolved a lot over the first decade.
Developers see mangling fiasco as soon as there try to mix libraries from different compilers or languages and you seem to agree on that. The fact that a lot of C projects use basically the same idea to organize there code to look like object could be standardized in C. No need to use C++ to do that.
Using C++ just to get a few objects is fun only until you get stuck at one of the overlong cryptic unintelligible error messages from the compiler.
C++ since 1989 is not as simple as you describe. But even before C++ 2.0 some dramatic choice make it a over complex language. The most obvious problem from my point of view is the lack of a standard and direct naming schema between class and his elements and methods that started the name mangling fiasco. If you look to numbers of big C projects, you will find far simpler implementation of something that look like objects.
Thanks for the JIT link, it very interesting.
I agree to your concerns: C must only integrate features that have proved to be widely approved, simple, clean, useful, and efficient.
Take for example the dynamic table allocation on stack or the dynamic initialization of a struct. Those features don't break existing code, but make new code more simpler to write and bring to the compiler a more direct indication of the goal of the code. I am certain that some useful features of a simple object programming model would be useful if introduced the same way in C. Don't get me wrong, I am not talking about a complex crap like C++ !
I disagree that this will remove flexibility. For example dynamic table allocation on stack or the dynamic initialization of a struct have not removed flexibility. There have standardized features highly desirable without forcing anyone to use them. After many decades of object programming evolution, I am certain that some basic OO features could now be safely integrated into C.
I agree that Java and C# have a cleaner and simpler object programming model than C++, but there are not popular (if even suitable) to write low level code. C is very successful because it usability span from the smallest microcontroller to very big projects. Support for almost all silicon is almost exclusively done in C and it's very unlikely to change quickly. I think that adding a pragmatic simple object model to C will make a lot of sense.
A lot of big projects already organize there code in a way that look like objects. Often this is a just a struct and associated functions. Some projects have something close to single inheritance, using there own function table or using library like for example GObject. All those C projects already take advantage of some object programming features. Integrating a common subset of those features into C will certainly bring an advantage to everyone.
Sincerely no sarcasm here, sorry.
C have evolved quicker that C++ on certain fun features like dynamic table stack allocation, dynamic struct initialization, etc... I don't think that C should be an experimental language, but I hope that it will continue to integrate fun features that have proved to be useful, clean, and efficient. A simple object programming model could be very useful if done in a cleaver way than do not introduce drawback like undefined name mangling for example.
C++ is not the only way to do object programming. If fact this is probably the most complex and crappy way to do it. A lot of others language have proven that object programming can be more simple. C is late in the object programming game and can take this as an opportunity to do it the right way.
I hope than C will evolve to add a clean simple and single inheritance object model without all the over-complex crap from C++.
A even more advance would be that C get an optional standard library comparable to boost and the like that make consensus in the developer community.
Finally a JIT would make it competitive to the increasing markets areas with high diversity of silicon processors architectures.
The open source PCB board layout tool has the same problem: It's called "pcb".
Like KiCad ?
What's more fun ?
1) Hello World! Today I publish a shiny new programming language that is better at XYZ compared to anything out there. Joint me and contribute.
2) Hello mailing list, this is the patches set version 18 of my 3 years effort trying to integrate the XYZ feature into the project. I hope this version address all the remaining complains about it.
3) Dear Steering Committee F.0x55/C-75, please find in attachment the version 24 of the 137 pages document "Proposal for adding feature XYZ" to the agenda for the next 10 years cycle of standardization.
I agree: a modification will only be local and not altering completely a such massive object. But in case of very small mass (imagine a few kilogram), a 1.1kW RTG could be able to alter it significantly.