|
|
|
|
|
by benschulz
265 days ago
|
|
This seems like an uncharitable reading of the post. > They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work. > Also blaming the users of your language for your language not being able to meet their needs isn’t a good look. Isn't that what the whole post is about though? They even say the following. > Returning to earth: we may be academics, but we are trying to build a real programming language. That means listening to our users and that means we have to support print debugging. The question is how? |
|
Things like this - they're painting users of programming languages as the ones being unreasonable.
> I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work.
From the article:
> We don’t want published packages to (a) lie to the type and effect system, or (b) contain print debugging statements > As a result, using dprintln in production mode causes a compilation error.
There is no documentation about the existence of build profiles or how they might work. I think you're reading too charitably.