Programming Languages on Crack

Max Samukha maxsamukha at gmail.com
Thu Jun 17 09:06:33 UTC 2021


On Thursday, 17 June 2021 at 02:02:58 UTC, Walter Bright wrote:

>
> The idea of putting it at the function level is to force (I 
> know,
> that sounds bad, but indulge me for a moment) the programmer
> to think about the decomposition of programs into safe and 
> unsafe
> code. Ideally, untrusted code should be encapsulated and 
> segregated
> into separate sections of code, with clean, well-defined, 
> well-considered,
> and well thought through interfaces.

No, the lambda approach will not lead to those. Just like every 
first D project out there abuses "static if" to hack around the 
limitations of "version", people will use something like "int a = 
() @trusted{ ... terrible hacks... }();" everywhere.

I think you are fighting a strawman here: we are not arguing that 
powerful features won't be abused. We are arguing that your 
safeguards will not prevent the abuse. By allowing immediately 
called nullary lambdas (sematic equivalent of blocks), you are 
not forcing people to think about anything but how to hack around 
the lack of trusted blocks.

I could play an experience card too, and say that the shittiest 
code I have ever seen was written to work around programming 
language limitations. So, your argument works both ways: yes, 
powerful features may and do lead to shitty code, and, yes, 
limitations may and do lead to shitty code.


More information about the Digitalmars-d mailing list