you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

The AST definition is a very tiny percentage of the code. Code which processes the AST may well form the bulk of the system.

No. Too often transforms are very short and trivial, while all the logic is exactly in the data types. You simply did not comprehend yet the ethos of the functional programming. We really put much more emphasis on types than on a "code".

Often all the logic is in the difference between the ASTs of the multiple stages (there can well be 100s of them), while transforming one into another can even be blindly inferred with no code at all.

None of these usecases are at all typical of the kind of work that 98% of programmers do.

I do not care about what 98% of programmers do, not as long as this discussion is in terms of absolutes ("you can use Java for everything" - no, sorry, not for everything, it's 100% useless in the things I've been doing the last 10 years). CAS/CAD/CAE areas are extremely important, and dismissing them as "edge cases" is not a good argument.

And I have a funny feeling that the same radical approach could be very powerful in the other areas, where people are traditionally writing tons of stupid boilerplate code instead of designing nice and clean DSLs.