Eliah_Lakhin

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.

It depends on how you define the observable pattern.

The fundamental components here are laziness and weak connections between graph nodes. Node values are getting materialized only when you observe them, and the system is flexible for live structural changes.

Usually, you don't need to materialize the entire graph when you need to observe just some nodes. Additionally, you can halt computations at any point in time leaving the graph in semi-actualized state, make extra changes to the inputs, and continue materialization of the nodes of interest. The algorithm will sort out all changes for you.

Essentially, incremental computations is just a term covering these features. You can organize the same system in terms of observers and subscribers.

Perhaps, classical Excel spreadsheets is the best illustration of the idea. Also, see my article on the topic: https://medium.com/@eliah.lakhin/salsa-algorithm-explained-c...

Well, I can ask you the same question. I don't see how you can make money using AI in the foreseeable future too. Even if it is possible today, once the critical mass of people will master this technology, the opportunity gone.

In the past there was a "human computer" profession[^1] where people earn money for calculating by hand. Soon they were replaced by just normal computers. But computers were rare and expensive. Not everyone could afford of having one. So, there was a period of time where the big business had an opportunity. This opportunity also gone, once the home computers widespread.

The businesses may be in advantage of selling products made with AI. But I foresee that the value of these products will degrade eventually, because everyone will manage to do more or less the same at home. Ordinary software will no longer be a thing you can sell or advertise easily.

You would have to try harder to produce something unordinary. And even if you do, it will be very easy to replicate for competitors using AI.

I think that maybe not today but in a few years the Internet will be full of generated content most users wouldn't trust, and wouldn't be interested in mostly. And there will be no novel ideas available for public, because any know-how will be carefully hidden.

To conclude, it's not just about "code quality". If you are making something unusual you can make by hand, that the AI cannot imaging, you have very serious reasons not to disclose it in a new reality.

[1] https://en.wikipedia.org/wiki/Computer_(occupation)

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.

A huge part of China's success stems from the fact that Nixon opened up U.S. markets to China, along with U.S. investment capital. It was a key strategic decision made by the United States to counter Soviet influence in Asia. China's reforms were merely an adaptation to the new opportunities that arose from this shift.

Another important factor was China's significantly larger population compared to the Soviet Union, combined with notably lower labor costs. All these factors eventually propelled the country to great prosperity. Without them, I think China today wouldn't look much different from any other East Asian country.

The Soviets simply didn't have such opportunities. Leaving aside the fact that Western countries never offered them a similar deal, Soviet labor simply couldn't match the industrial productivity enabled by the cheap workforce of East Asian countries.

The USSR had vast land and abundant natural resources, but its population density was relatively low. Additionally, it already possessed advanced technologies and a well-developed industrial base. From the U.S. perspective, such a country looked more like a potential (and actual) competitor rather than just another member of the Western economic system.

I'm not a big fan of a planned economy. And I believe that the lack of social freedoms and democratic institutions, typical of Western countries, was a major factor in the Soviet collapse. But regardless of the decisions and reforms Soviet authorities could have made after World War II, I think the country was doomed either way.

The Soviet Union simply didn't have a large enough population to effectively develop such an enormous landmass. After WWII, significant male losses and the effects of the second demographic transition led to continuous population decline. The only reasonable course of action would have been to relinquish part of its global influence and territory, which it eventually did — but perhaps too late. However, the authorities of any country rarely want to give up power, and the Soviets were no exception.

As for turning points, I don't think it was the NEP. More likely, the Communist (October) Revolution itself was the crucial historical moment. The Russian Empire was a relatively promising state, evolving in the right direction. It was gradually building democratic institutions and transitioning to a liberal economy. Its industrial development was progressing similarly to other European countries — perhaps with some lag, but still moving forward.

Perhaps the real turning point in Russian history was when radicals, driven by controversial economic and social ideas, inherited a wealthy country and used its potential for large-scale social experiments.

What does the developer's experience with incremental parsing feel like?

It's essentially the experience most of us already have when using Visual Studio, IntelliJ, or any modern IDE on a daily basis.

The term "incremental parsing" might be a bit misleading. A more accurate (though wordier) term would be a "stateful parser capable of reparsing the text in parts". The core idea is that you can write text seamlessly while the editor dynamically updates local fragments of its internal representation (usually a syntax tree) in real time around the characters you're typing.

An incremental parser is one of the key components that enable modern code editors to stay responsive. It allows the editor to keep its internal syntax tree synchronized with the user's edits without needing to reparse the entire project on every keystroke. This stateful approach contrasts with stateless compilers that reparse the entire project from scratch.

This continuous (or incremental) patching of the syntax tree is what enables modern IDEs to provide features like real-time code completion, semantic highlighting, and error detection. Essentially, while you focus on writing code, the editor is constantly maintaining and updating a structural representation of your program behind the scenes.

The article's author suggests an alternative idea: instead of reparsing the syntax tree incrementally, the programmer would directly edit the syntax tree itself. In other words, you would be working with the program's structure rather than its raw textual representation.

This approach could simplify the development of code editors. The editor would primarily need to offer a GUI for tree structure editing, which might still appear as flat text for usability but would fundamentally involve structural interactions.

Whether this approach improves the end-user experience is hard to say. It feels akin to graphical programming languages, which already have a niche (e.g., visual scripting in game engines). However, the challenge lies in the interface.

The input device (keyboard) designed for natural text input and have limitations when it comes to efficiently interacting with structural data. In theory, these hurdles could be overcome with time, but for now, the bottleneck is mostly a question of UI/UX design. And as of today, we lack a clear, efficient approach to tackle this problem.

This is likely the first gamedev project written entirely in Rust and Vulkan to achieve significant financial success on Steam.

I'm genuinely proud of the authors — they've set an inspiring example and given us hope for a bright future where the Rust ecosystem serves as a foundation for unique and creative game development projects.

Using the term "open source" for every project published in source code form might not be ideal — not just because of the "zealots", but also because it may not serve the author’s best interests.

The term "open source" has a well-established reputation as "free as in beer", whether we like it or not. So why attach such a label to a commercial product?

Commercial software isn't inherently a bad thing. In fact, it's even better if the author or business can afford to publish it in source code form, making their services more transparent to end users.

As for the term "source available", it isn't as well-established as "open source". Its meaning may not be clear to the audience, and there's a certain lack of trust associated with it. However, this could change over time if more projects identify as "source available" and maintain clear and honest distribution and usage policies.

The current state of web development engineering is largely the result of how startup economics have functioned over the past decade.

A startup's market value is often closely tied to its number of employees. From an investor's perspective, a company with 1,000 employees is typically valued much higher than a small team of 37 programmers — regardless of the revenue generated per employee, or even if the company isn’t generating revenue at all. This is largely because interest rates remained very low for a long time, making it reasonable to borrow investment funds for promising companies with large staffs.

However, those employees need to be kept busy with something that appears useful, at least in theory. I believe this is one of the primary reasons we see such complex solutions for relatively simple tasks, which sometimes might not require a large team of advanced web developers or sophisticated technologies at all.

I'm currently unemployed, and my last job ended over two years ago, so my experience is more related to the pre-AI boom era.

Back then, I often felt that the software products we were developing could have been created by much smaller teams of experienced programmers, or even by a single programmer. I'm referring specifically to direct programming, excluding management, QA, and devops. My professional experience is primarily with startups and small companies, but I believe this idea could extend to some larger products as well.

This raises the question of whether I, as a programmer, was productive enough. I believe that my colleagues and I were quite productive, and we performed our daily tasks honestly and fairly. However, I feel that our responsibilities were artificially limited. I think my productivity could have been much higher if my responsibilities within the company had been expanded. At least, this is what my personal, non-commercial experience with my pet projects in my spare time suggests.

I understand that a pet project is not the same as a business solution, but I believe the core issue is not that AI affects programmers' productivity, but that AI has helped management realize that increasing the number of programmers does not necessarily improve product quality.

I also found Josh Christiane's video on this topic very insightful: https://www.youtube.com/watch?v=hAwtrJlBVJY

On a more general note, it's often challenging to sell anything to the software developer community, regardless of the licensing terms you choose. I believe you'll gain commercial traction only if your product is closer to the real market. In this sense, using the MIT license may expose your project to the risks you mentioned.

As for community feedback, it doesn't necessarily have to be negative. Recently, I published my project under a non-standard license and received generally positive feedback[1], despite my project being in a very niche field.

[1] https://news.ycombinator.com/item?id=40747845

You can publish your project under your own licensing terms. In your license, you can prohibit the creation of derivative works based on your source code, except for building executables for personal use, provided your clients obtain a commercial license from you. This way, GitHub users can audit and fork your repository, but they won't be able to sell your software under their own terms.

I'm not a lawyer, and it's generally a good idea to consult a specialist when drafting licensing terms. However, in my personal opinion, it's often better to draft a project-specific license yourself to start, rather than using a popular open-source license, most of which are not aligned with typical commercialization goals.

If I go to a bookshop, take a book off the shelf and start reading it, I am not infringing any copyright.

I'm not sure this is applicable to licensed programs because a book is sold, not licensed.

The output of a machine simply does not qualify for copyright protection – it is in the public domain.

As far as I know, the output of a compiler that builds executables from copyrighted source code is still subject to copyright protection. Is software like an LLM fundamentally different from a compiler in this regard?

In my opinion, the author's argument has several flaws, but perhaps a more important question is whether society would benefit from making an exception for LLM technologies.

I think it depends on how this technology will be used. If it is intended for purely educational purposes and is free of charge for end users, maybe it's not that bad. After all, we have Wikipedia.

However, if the technology is intended for commercial use, it might be reasonable to establish common rules for paying royalties to the original authors of the training data whenever authorship can be clearly determined. From this perspective, it could further benefit authors of open-source and possibly free software too.

Imho it would only be market failure if that freedom disappears

There is nothing inherently wrong with Facebook making React open-source. React undoubtedly benefits everyone.

However, the issue lies in the fact that this practice doesn't create a true "market". Facebook has made a relatively small and insignificant portion of their source code available for free, which doesn't impact their business significantly. Meanwhile, they have encouraged thousands of programmers around the world to develop React extensions and publish them for free under similar terms. For an individual programmer, unlike Facebook, this means giving away 100% of their work effort without charge. While this benefits society in terms of knowledge sharing, it almost always financially benefits businesses and big tech companies.

Overall, this model creates a situation where most programmers end up doing part of the job for businesses for free, and they have to earn their living by working for these companies as well.

This model exploits programmers' labor in two interconnected ways. Simultaneously, there is widespread public promotion that publishing under OSS licenses is moral and the only way to go.

The free/open-source movement has greatly benefited society by encouraging people to overcome their fears and start distributing their work in the form of source code rather than just precompiled binaries ("closed source").

However, the core idea of sharing source code is not exclusive to the FOSS movement. This concept aligns with the original intentions of the Berne Convention. The United States adopted the Berne Convention relatively late, in the late 80s if I'm not mistaken. Before this adoption, source code made publicly available without prior copyright registration procedures was effectively considered public domain. This situation allowed businesses and startups to exploit these sources to create closed-source commercial products without crediting the original authors.

The Berne Convention was a game changer. It introduced a new rule that simply making source code publicly available automatically grants the author exclusive copyright of their work, without any bureaucratic hurdles.

This rule opened up new possibilities for programmers to create open-source projects in the broadest sense. Nevertheless, due to historical reasons, it was not an easy task for the public to understand this new reality. The FOSS movement worked hard to convince people that publishing software in source form is perfectly fine.

However, the free-software philosophy can be quite restrictive compared to what the Berne Convention actually allows authors to do with their work. This ideology is so pervasive today that many programmers believe that publishing source code must involve using an OSI-approved (F)OSS license. Any deviation from this is often seen as supporting outdated business models and harming the programming community's ability to share their work with the public.

These misconceptions likely arise because the FOSS movement has taken the lead in promoting the principles of the Berne Convention, adding its ideological restrictions. The rarely acknowledged truth is that the Berne Convention offers a wide range of possibilities that could benefit the community of authors more than big-tech corporations. The Four Freedoms of Free Software significantly restrict these options for authors.

More importantly, big businesses have already adapted to this new reality and are utilizing this philosophy to their advantage.

build out a compatible API that can be used with editors/tools that use tree-sitter's library?

That's an interesting idea. Tree-Sitter and Lady Deirdre are quite different in their approaches to parsing. Tree-Sitter is a GLR parser, while Lady Deirdre is a recursive-descent parser. In the Lady Deirdre API, there are customizable traits that let you define new types of files with parsers ("documents" in terms of Lady Deirdre). Perhaps it would be possible to create an adapter, but I would implement it as a separate crate.

what happens with open-source projects that use this that are then used in commercial projects?

Good question. The idea is that if you link to Lady Deirdre in the Cargo.toml dependencies, it is up to the commercial project authors. They will compile the actual executable intended for selling by downloading both your crate and my crate. However, I'm not a lawyer, and this is not legal advice. Just my thoughts.

It's 5 thousand after you've made 200 thousand though?

That's correct. The license agreement requires purchasing a commercial license per product if it reaches a certain revenue threshold. I believe this price should be feasible for a business, and this restriction is not unfair for regular programmers either. To clarify, the license needs to be renewed annually to continue receiving new versions from me. Additionally, I reserve the right to change the price in the future. However, license renewal is not a strict obligation. You can continue using the previous versions if you buy the license at least once.

The idea is to replace the donation model widespread in typical OSS projects with a formal obligation to purchase a license. I believe this approach more accurately expresses what the authors really want in exchange for their labor.

Thank you for your feedback!

I agree with your point about the licensing. I would also add that tools for the development of compiler front-ends are quite a niche market. So, honestly speaking, I don't plan to earn much from my project regardless of the license terms. This work is part of a higher-level in-progress toolset, which is closer to the end users. I have dedicated it as a separate project primarily for public preview, with some restrictions on distribution and use, as I haven't decided on the overall toolset distribution model yet. But it is possible that I will change the licensing terms of Lady Deirdre in the future to something less restrictive (maybe even MIT) to make it more popular, this is just not my current goal. I apologize for any inconvenience my current licensing terms may cause.

You are right, this is indeed the second iteration of the project. Since the first iteration (released about a year ago), many things have changed and been reworked. The most notable change is the introduction of the semantic-analysis framework. Lady Deirdre 1 was merely an incremental parser library.

why the seemingly needless location of everything down in a "work" folder?

It's just easier for me to organize the filesystem this way on my local machine. Everything that is unrelated to the development is outside of the work directory. Also, the license agreement refers to the "work". Perhaps it would be clearer for users if the work directory is clearly dedicated.

Is there something else that you envision one day living at the top-level which you just planned for by putting everything someone would care about one further click away?

Everything that I planned to publish that is related to Lady Deirdre is already in the repository. I use this project for my other programming language project that I plan to release soon, but it will be in a separate GitHub repo. Actually, Lady Deirdre initially was separated from the language project codebase as I thought it may be useful for other programming language authors.

The problem with Vulkan and the similar APIs is that the authors of the specification attempted to make an industry standard that would be easier to implement by the GPU manufacturers, but at the same time it would still be quite high level and abstract so that the end users could use it without care of how the devices work in too much detail.

The issue here is that if the users chose Vulkan, they probably do care about these details, but the API makes it totally obscure for them if they don't have prior experience with the GPU architectures.

At the same time the API is too low level for other users who want to just start drawing polygons on the screen here and now like they did with OpenGL.

I work with Rust most of the time. As of the pure functional languages, yes, perhaps using parser combinators is better.

I think it all depends on the language, but I found it (usually) easier to implement the recursive-descending parsers just manually. This may include combination approach too, but using my own combinatorial and domain-specific functions.

In a nutshell such a parser is PEG in a sense that the choice is ordered, but with little to no test expressions. In other words, I try to stick to lookahead-1 most of the time. Left recursion quite often could be resolved by lifting the branches to their siblings rather than re-parsing the same things many times using the cache (packrat). In fact both approaches, the packrat and the nodes lifting, are the same in a nutshell, but nodes lifting is usually easier to maintain (again, it all depends).

Writing the parser manually, or in other words a set of relatively simple mutually recursive functions, in my opinion, is not the hardest problem in practical engineering. At least it's not so hard when you have a mental model of the language's syntax upfront.

If the language fits specific class of formal grammars very well, perhaps it would be not so hard to implement it using the parsers generator tool. But it is likely there will be edge cases that are hard to express properly using the formal grammar, and fighting with the tool specifics will waste a lot of your time rather than benefit you.

Well, my point was that the speech by itself is not a good criteria to estimate the intellect. This is not only applicable to machines but to humans as well. I assume that the primary evolutionary determined purpose of a speech function was convincing rather than the source of reasoning. Even though we use natural languages to broadcast the information, the languages usually overwhelmed with linguistics and psychological tricks to make an illusion of usefulness and novelty of this information. Even if the information was truly novel, it's usually hard or even impossible to find the roots. This is one of the reasons of why most people prefer to learn rather to invent. Broadcasting of information of inventions made by someone else is much simpler and usually more beneficial than researching something from scratch. And our natural language specifically designed for such forms of broadcastings.

In this sense if the ML developers would be focused on the inventions automatisation, I would expect that they would choose something more formalised than the natural language.

Anyway, whatever way and methods they chose I think the better external estimation criteria of intelligence should be the ability to make completely new things that clearly didn't exist before. Not just reasoning about existing one. After all, it's not a new thing that computers are able to deduce. Any programming language can do that better than any chat bot.

I was hoping that it would be clear from the context, that LLMs are more advanced than birds in just the ability to synthesise the speech close to human speech in its complexity.

Sorry, I didn't mean to offend the parrots. I like parrots too! :)

I don't think that following the primal benefit would be a good estimation for intelligence, despite the fact that such behavior is common for most species.

What makes human specie special is the ability of some individuals to create new things that didn't exist before. That's a loose criteria of course, because most individuals just follow educated social constructs for their entire life.