Hi Alexey,


> Hi, Federico.
>
> I'm a student of software analysis & design, how many people.
>
> I started project sourceforge.net,
>
> but Antlr parser runtime with my grammar is very slow.
>
> Can you advise me how to increase the speed of the parsing?
It is hard to give advice in general, once should look at the specific grammar and the typical examples of files being parsed.

Sometimes the best solution is to change how the grammar is written, in other cases you can tweak the prediction algorithm being used.

I did not watch it yet but here there is a video of a guy using an ANTLR profiler to find performance issues: www.youtube.com
>
> Now I am studying theory of DFA,
> algorithms of parsing(Asaptive LL(*), LR)
> and sofware: Roslyn, Sam's Hawell Antlr4.Runtime, GNU Bison and other.
A lot of stuff! Luckily it is all interesting.

Cheers,
Federico
>
> My head will soon burst. ;o)
>
> WBR, Alexey


Hi Alexey,



The typical project involves more than one person. It involves developers, project managers, domain experts. These different figures need to communicate somehow.

Even if we work alone we take notes, sketch some basic diagram or just leave comments for our future self.

We explain the code in documentation (sometimes...), over chats we have on Slack or in front of the coffee machine. We write reports or have stand-ups to describe the status of the project. We get and write emails, so many of them. We strive to communicate in different ways, with changing fortunes.
And why do we need to communicate?

Because otherwise all sort of things could go wrong:

management who does not know about a delay fail to plan accordingly,
developers who misunderstand requirements end up programming something else,
features that are marked as implemented are not really.

So what?

One solution would be to use the programming languages as the source of information for all the people involved in the project. How so?

In different ways:

We could use Domain Specific Languages which are easily comprehensible for domain experts. We would just show them the code and they could let us know whether is correct
We can process language and derive diagrams or graphs. DSLs are higher level languages and it is possible to derive useful documentation. Think about an ER Diagram expressing a SQL schema
We can use demos: we can do that even without DSLs, but with DSLs is sometimes possible to write easy-to-use simulators, which non-developers could use for trying the code from day one

Languages serve primarily one goal: to communicate. We should remember that and plan to use languages that make it easier, reducing the time we spend writing or reading words about the code.

What about you? Did you experienced communication issues?

Cheers,
Federico
My blog on Language Engineering: tomassetti.me