I'm really struggling to understand the benefit that you say you'll get. The linear form that the with: label gives you is really just what we already use with a different accent. The cost of testing or not is not substantially different, but the cost of allowing long linear functions, needing additional editor support, requiring additional concepts for language users and the compiler, and not being able to use already well establish refactoring tools that are well understood and tested, all make it feel like a net loss of benefit.
All of the things that you are wanting to do with the with: label/directive can be done with functions, arguably in more cognitively friendly way (for example in you with: examples you use comments to explain what each stanza does, making room for divergence between commentary and code; using functions, the function name *is* the comment). On Thu, 2020-03-05 at 14:17 -0800, Warren Stephens wrote: > Dave, > > A key amount of testing here and there is a great thing, but I think > that folks greatly underestimate the amount of time (per your > example) and effort put into increasing test coverage only to have a > project shut down! There often is no "long run"! Whereas, what I > call "real world" testing -- like launching something 10,000 times > quickly (50,000 times today!) in the actual cloud infrastructure have > produced far far more benefits to me on a time/effort basis -- like > when I found that I can get a zero return code and the action did not > succeed anyway. It happens! > > I believe there is a principle at play here where something that is > "teachable" appears to be more important than something that isn't > "teachable". Like statistics. ha ha! > > The other thing is that I do not see much difference between what you > (and others) refer to as "internal" versus "external". When I > refactor a bit of code out then it basically looks the same to me. > And a step in a Step Function can call other step functions -- so you > don't know whether you are being "internal" or "external" really -- > like a fractal. > > So I should invent a fractal programming language -- where every > function must be defined within another function -- have people write > tests for that! > > Best, > > Warren > > -- > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/90922f81-d536-4598-98b3-7b1b612c678b%40googlegroups.com > . -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9e4cfbd65aa40dbe912b4bb7181fa2154bde4499.camel%40kortschak.io.
