3 ms·
> If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same? Well, t
by suby 3y ago
> If Circle does provide a number of desirable features and its compiler can be built by a single person, then why shouldn't the committee do the same?
Well, there are downsides to taking Circle's approach which I think are worthwhile to mention. Languages are preferable to everyone creating their own custom DSL. They provide a single target that everyone is able to learn, it allows one to work in a much larger body of work without friction.
When I pull down a library or codebase, I want to be able to immediately hit the ground running instead of having to understand every aspect of how the developers have tweaked the language to suit their preferences, and how each of these tweaks interact with each other. You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer -- it invites a combinatorial explosion with conflicting features that don't play nicely with each other. But mostly, it's about maximizing one's ability to pull down and work in foreign codebases without having to learn a new dialect of a language.
- vanderZwan 3y agoThis isn't quite a DSL approach though: the features are turned on and off locally, and don't "escape" from that local source. So provided that one knows the features that can be turned on or off they can just read the source code top to bottom without having to trace which feature was accidentally set in a different file. Also, re: > You probably shouldn't rely on people making these choices themselves, because you don't want everyone being a language designer This would be true for any other language, but with C++ one already has to figure out which subset of features to use, which is basically the same type of choice as turning Circle features on or off.