Comments by "" (@grokitall) on "TRACTOR - C to Rust AI Compiler By DARPA" video.

  1. ​ @ITSecNEO bull, android is basically the linux kernel, with a few android specific tweaks. the linux kernel is huge with a lot of push back against rust for anything the rest of the kernel might need to depend on. the advantages for rust in a mixed codebase are vastly overstated, as it is hard to call rust from c, and calling c from rust is inherently limited due to the differences in language design.
    2
  2.  @ITSecNEO  according to the android website, the android kernel is a modified lts linux kernel with some extra patches which have not been upstreamed yet. given the size of the linux kernel, and the resistance of upstream to take rust code for anything other code might depend on, the amount of rust in the kernel has to be minimal compared to its size.
    2
  3. llms and statistical ai in general work by having the user tweak the input until the output becomes good enough. unfortunately, work on refactoring demonstrates that relatively minor tweaks cause the input code to become completely different code rather than modified code, making version control largely broken for that change. lots of different work implies that without a good model, you don't produce good updates, hence the doubt, as statistical ai has no model of what is right, and how it might be wrong.
    2
  4.  @alst4817  no, i am assuming that due to the model being black box, it does what it does, but you don't know and often can't know that it is not coincidentally giving answer that happen to match what useful answers would be. even worse, due to the lack of modeling the problem space involved in this type of ai, it cannot make use of all sorts of useful feedback about why that particular answer would be garbage, and most black box ai is unfixable if a problem is encountered. the only solution to that is to use white box symbolic ai methods, which actively model the problem space and have multiple feedback loops to stop whole classes of wrong answers from occurring, making them patchable.
    2
  5.  @alst4817  my point about black box ai is not that it cannot be useful, but due to the black box nature, it is hard to have confidence that the answer is right, that this is anything more than coincidence, and the most you can get from it is a possibility value for how plausible the answer is. this is fine in some domains where that is good enough, but completely rules it out for others where the answer needs to be right, and the reasoning chain needs to be available. i am also not against the use of statistical methods in the right place. probabilistic expert systems have a long history, as do fuzzy logic expert systems. my issue is the way these systems are actually implemented. the first problem is that lots of them work in a generative manner. using the yast config tool of suse linux as an example, it is a very good tool, but only for the parameters it understands. at one point in time, if you made made any change using this tool, it regenerated every file it knew about from its internal database, so if you needed to set any unmanaged parameters in any of those files, you then could not use yast at all, or your manual change would disappear. this has the additional disadvantage that now those managed config files are not the source of truth, this is hidden in yasts internal binary database. it also means that using version control on any of those files is pointless as the source of truth is hidden, and they are now generated files. as the code is managed by those options in the config file, that should be in text format, version controlled, and any tools that manipulate them should update only the fields it understands, and only for files which have changed parameters. similarly, these systems are not modular, instead being implimented as one big monolithic black box, which cannot be easily updated. this project is being discussed in a way that suggests that they will just throw lots of data at it and see what sticks. this approach is inherently limited. when you train something like chatgpt, where you do not organise the data, and let it figure out which of the 84000 free variables it is going to use to hallucinate a plausible answer, you are throwing away most of the value in that data, which never makes it into the system. you then have examples like copilot, where having trained on crap code, it on average outputs crap code. some of the copilot like coding assistants actually are worse, where they replace the entire code block with a completely different one, rather than just fixing the bug, making a mockery of version control, and a .ot of tne time this code then does nit even pass the tests the previous code passed. then we have the semantic mismatch between the two languages. in any two languages either natural or synthetic, there is not an identity of function beteeen the two languages. somethings can't be done at all in the language, and some stuff which is simple in one language can be really hard in another one. only symbolic ai has the rich model needed to understand this. my scepticism about this is well earned, with lots of ai being ever optimistic to begin with, and then plateauing with no idea what to do next. i expect this to be no different, with it being the wrong problem, with a bad design, badly implemented. i wish them luck, but am not optimistic about their chances.
    2
  6. ada was commissioned because lots of government projects were being written in niche or domain specific languages, resulting in lots of mission critical software which was in effect write only code, but still had to be maintained for decades. the idea was to produce one language which all the code could be written in, killing the maintainability problem, and it worked. unfortunately exactly the thing which made it work for the government kept it from more widespread adoption. first, it had to cover everything from embedded to ai, and literally everything else. this required the same functions to be implimented in multiple ways as something that works on a huge and powerful ai workstation with few time constraints needs to be different from a similar function in an embedded, resource limited and time critical usage. this makes the language huge, inconsistent, and unfocused. it also made it a pain to implement the compiler, as you could not release it until absolutely everything had been finalised, and your only customers were government contractors, meaning the only way to recover costs was to sell it at a very high price, and due to the compiler size, it would only run on the most capable machines. and yes, it had to be designed by committee, due to the kitchen sink design requirement. the different use cases needed to fulfil its design goal of being good enough for coding all projects required experts on the requirements for all the different problem types, stating that x needs this function to be implemented like this, but y needs it to be implemented like that, and the two use cases were incompatible for these reasons. rather than implementing the language definition so you could code a compiler for ada embedded, and a different on for ada ai, they put it all in one badly written document which really did not distinguish the use case specific elements, making it hard to compile, hard to learn, and just generally a pain to work with. it also was not written with the needs of compiler writers in mind either. also, because of the scope of the multiple language encodings in the language design, it took way too long to define, and due to the above mentioned problems, even longer to implement. other simpler languages had already come along in the interim, and taken over a lot of the markets the language would cover, making it an also ran for those areas outside of mandated government work.
    1
  7. because rust is basically c with constraints, so it can be done incrementally. most valid alternatives are not, so you would have to translate everything at once.
    1
  8. ​ @notsojharedtroll23 arpa proposed the arpa net for two reasons. 1, incompatible machine conventions meant that having to pass data between incompatible systems was a real pain. 2, literally everything else on the books was taken away from them and shoved into nasa, leaving them scrambling around trying to prevent congress from declaring them irrelevant and killing their funding. with this, and a few other similarly big projects, they managed to stay afloat long enough to get back on track.
    1
  9. most kernels will not be rewritten, they are just too big. moving unix from assembler to c was an anomaly, as it would need to be ported, and c was written as a research project, so rewriting in c tested the design of c and made a lot of the code portable.
    1
  10.  @ITSecNEO  according to the android website, the android kernel is a linux lts kernel with some patches which have not been upstreamed yet. given the resistance from the kernel community to take anything but c code for things c must depend on, the percentage of non c in the kernel must be minimal. while you can call c code from c++, and from rust, i am not sure how well it works the other way around.
    1