Eliah_Lakhin

I want to add that AI-generated code isn't FOSS because it's not a _source_ code at first place. This is a generated code. All other reasons, in my opinion, are secondary and may change over time.

Publishing generated code is not unique for AI. For example, it's a common practice to generate a parser using YACC from source grammar files, and then publishing both. The main thing here is that no one claims that this code is a "source code", no one saying that it has been written by someone. It is perfectly fine to put a comment directly in the file's text that it has been generated by YACC.

If people would be more accurate on this matter, and wouldn't publish generated code alongside with OSS projects, a notable part of the problems we discuss today wouldn't exist.

I'm not fully confident that they truly want to show what they are interested in, even if they don't have deep expertise in it. My feeling is that there is a notable portion of projects being the result of prompting a chat-bot for ideas to develop. ChatGPT, what I can do? Make a website about wine. :)

That might be an issue for the software dev in general, I fully agree with you here, but my question was not about it. I don't understand the motivation for publishers of those projects. They literally don't gain anything positive in return by announcing the project. Sometimes the community pushed back, but more often just ignores the posting as spam.

Now when the big LLM companies create their products by accumulating a notable portion of copyrighted creative works (including computer programs) from Internet, it does not count as copyright infringement or competition (or "theft"). It is considered as "fair use". So, why training LLMs on other LLMs is not fair use too?

> If you don’t like that, if you don’t like people to use your products, all you [have to do is] know your customers, and disable the service

Considering the current situation, I understand Mr. Huang point, but that's not how the copyright framework assumed to be working from the beginning. It should protect both small actors (authors) and the big companies from unrestricted use of creative works. Now this mechanism seems to be practically dysfunctional.

And a big portion of this lies on shoulders of proponents of permissive OSS, who defend an idea of (almost) unrestricted use of their source code texts for many years, and long before mass LLM scrapping became a thing.

In the article it is assumed that the object of the node owns a vector of it's dependencies locally. We don't need to access the entire edges set all at once. The evaluation process is recursive. Once the node's function re-evaluate, the vector is being updated. Though, the re-evaluation is not happening for every node every time due to the caching system based on the node's value hash comparison and the two-layer monotonic versioning in case of present algorithm. Other incremental computation algorithm have different approaches in verifying on whether the node's function needs to be re-evaluated. Each approach have pros and cons.

You are right, it is assumed that in general the average node function evaluation is more expensive than the cost of graph management. It's not too expensive, but if by chance node's function is notably cheaper, this approach could be suboptimal in certain cases.

The key insight here is that it is assumed the end user don't need to actualize the entire graph each time any random input is being changed. The user observes only a small portion of the graph nodes in real time, and the incremental computation system ensures to minimize required evaluations. If this local observability is not a goal the system is not incremental by definition. For example, in case of Spreadsheets the entire table could be 10000x10000 cells, however the end user typically sees only a small portion of the table on the screen. On a general note the incremental computation systems are closely tied to the GUI-related tasks.

I meant that the graph (DAG) structure is not necessary need to be sealed and defined upfront. It could be computed and changed on the fly by the same function that computes node's value. Assuming that the node value computation function is a pure function without side effects (e.g. it's output depends purely on inputs) the function may read other node values directly, and the act of reading would establish graph edges transparently for the user. The next time compute function is being invoked it could re-subscribe on the different nodes hence changing graph structure on the fly. The user also can remove or add new nodes in between of the node values materialization. In other words, the act of subscription between nodes in the incremental computation system is typically tracked more transparently for the user than in the system with explicit observer-subscriber primitives. Even though, this is implementation dependent. The observable pattern could be designed transparently too. Perhaps, "flexibility" would be better term.

From the purely utilitary position maybe you are right, but my point was about arts and entertainment. Using the content generation tools might be useful in certain situations, but it's not joyful when the robots do the job for you.

Imaging that you purchase a video game, but then use LLM to play this game for you. Another example is Chess. Stockfish is more efficient than most Chess players, but playing Chess using programming assistant (even a little bit) is no longer a sport competition.

I also agree that not everyone like programming, and see it just as a job to be done.

I'm not quite understand what "language-extrapolation" actually means.

Personally, I don't use AI because I like to program myself. There are many other reasons, but this simple one dominates.

I upvoted your comment. I share your view and just wanted to say you're not the only one who thinks this way.

> As far as memory-safety goes, it really isn't close to being the most important thing unless you are writing security critical stuff.

Safety is the selling point of Rust, but it's not the only benefit from a technical point of view.

The language semantics force you to write programs in a way that is most convenient for the optimizing compiler.

Not always, but in many cases, it's likely that a program written in Rust will be highly and deeply optimized. Of course, you can follow the same rules in C or Zig, but you would have to control more things manually, and you'd always have to think about what the compiler is doing under the hood.

It's true that neither safety nor performance are critical for many applications, but from this perspective, you could just use a high-level environment such as the JVM. The JVM is already very safe, just less performant.

It works as long as a country primarily spends its income on internal development. Today's Russia is a relatively prosperous country with high living standards, at least in big cities. Perhaps these standards are even higher than in some EU countries. And they are certainly higher than at any point in Soviet history.

However, to a large extent, this is the result of cutting expenditures on projecting Soviet influence abroad. The Soviet Union had enormous spending on subsidizing friendly regimes and their economies around the world, as well as maintaining a military presence. The same applies to some former Soviet republics that the USSR had to subsidize for decades.

I think we are observing similar processes in the United States today. They are attempting to cut spending and perhaps even reduce their military presence simply because they cannot afford it in the long term without sacrificing their own prosperity.