Eko: New Programming language write entirely in D (Feedback welcome)

[pouya1dev]

On Saturday, 22 August 2026 at 10:14:23 UTC, user1234 wrote:
> On Saturday, 22 August 2026 at 09:53:14 UTC, pouya1dev wrote:
>> On Saturday, 22 August 2026 at 09:18:36 UTC, user1234 wrote:
>>> On Saturday, 22 August 2026 at 08:38:39 UTC, pouya1dev wrote:
>>>> On Friday, 21 August 2026 at 20:44:37 UTC, user1234 wrote:
>>>>> [...]
>>>>
>>>> I checked the link you gave 
>>>> https://github.com/beast-lang/beast-dragon and it seems that 
>>>> this language is no longer being updated. Because its last 
>>>> commit was 8 years ago. Also, the developer himself said 
>>>> that he has stopped developing the project. But I still 
>>>> think it is a great resource to learn. I think it could 
>>>> become a successful language. I was wondering if I could 
>>>> email him and he would respond? If so, that would be great.
>>>
>>> That a meme "dont ask to ask, just ask". The author 
>>> explicitly told me on IRC that his preliminary work can be 
>>> used, i.e he switched to something else. The licence also 
>>> gives you rights.
>>>
>>> Before using Beast as a base for something else, however, I 
>>> would consider a bit how things are organized. If you look 
>>> well, each node had its own source file, which is not 
>>> something I liked. The big 5000 SLOCs source is not great 
>>> either but actually, with the visitor pattern, that's often 
>>> just N micro-programs, with N the number of nodes.
>>
>> Also, having each node in its own file can be useful at first, 
>> especially when you are trying to find where a bug is. But as 
>> the project grows, maintaining and navigating all those small 
>> files can become a nightmare.
>
> Man, I never had an issue with debug infos. GDB just gives you 
> the right place, hopefully. That does not matter if it's a 200 
> sloc file or a 5000 one.
>
> My last message was really more about the architecture. Too 
> much source files in a compiler has an impact. Typically you'll 
> have 3x syscalls to put the content of the file in a buffer. 
> (1.get the size, 2.open, 3.read)

I agree that having too many source files can have an impact on 
compilation and I/O, especially when the compiler has to open and 
read many small files.
I have also used GDB quite a lot, and it is an excellent tool for 
finding runtime problems and tracking down where something goes 
wrong.

However, when the problem is in the architecture or design of the 
language itself, a debugger usually cannot tell you that the 
architecture is wrong. You often have to manually follow the code 
and understand how the lexer, parser, AST, semantic analysis, and 
interpreter/compiler interact.

That's why I prefer a balance: not thousands of tiny files, but 
also not one huge source file containing the whole compiler. I 
think grouping related functionality into reasonably sized 
modules makes the architecture easier to understand and maintain.