Re: [Boston.pm] Tech Meeting - benchmarking Perl5 vs Perl6 (Boston-pm Digest, Vol 126, Issue 7)
On 12/12/13 2:01 AM, Tom Metro wrote: Bill Ricker wrote: Tuesday December 10, 2013 E51-376 Tim King - Benchmarking Perl6 vs Perl5 * Perl 6's suitability for production. (Your definition may vary.) * Experiences of the state and stability of Rakudo. * Benchmarks of my favorite P6 features. * Lines of P6 code from everyday life. * Some comparisons of P6 with P5. If you missed the talk, we're working on getting a version posted online. (Tim confirmed that the audio capture was successful, and the slides have been rendered to video. Need to edit the two together.) A PDF of the slides will also be posted. I posted a PDF of the slides here: http://j.mp/1fnGOmN I'd like to release the audio. Any problem, those of you who spoke and were recorded by my lapel mic, with my releasing your questions and comments? (Feel free to email me directly with concerns.) -TimK ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Trying to learn about the problems with eval()
Ben Tilly wrote:
I agree that using eval here is wrong. But I still
don't see action at a distance.
You can argue about whether it is action at a distance, but you
have tight coupling between the internals of make_generator
and the string passed into it that was generated from very far
away.
Correct. A function that uses eval() does so in its own context. I don't
see what makes this a problem with eval(). Rather, it's a concern that
affects the software design.
The problem in this example is that make_generator doesn't make a
generator.
I know full well what the problem is. And the result is that you
cannot consider using code generation for a situation like this.
Not if you want to make a generator as you have tried, no. My point was
that this is not a problem with eval(); it's a problem with your
proposed design.
I use eval() when I don't know what the code is until runtime, or to
execute code generated in one place in a context generated from another.
But I can't recall a case like the latter that wasn't also an instance
of the former.
sub foo {
my $x = 7;
my $generator = sub{++$x};
print $generator-() for 1..5;
}
But in general you're now
prevented from adding various kinds of syntactic sugar,
manipulating the passed in code before compiling it, etc.
If you really need to manipulate the code, you apply the syntactic sugar
when generating the code string. Then you invoke eval() in whatever
context the code should execute.
Or alternatively, you can pass to the code-generator an evaluation
context that the generated code will use. One might use a technique like
this when using Perl as a scripting language within a Perl program, for
example.
Note that $generator... is a true coroutine.
It is not a coroutine. It is a closure.
It is both a closure and a coroutine.
-TimK
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Trying to learn about the problems with eval()
Hi, Ben. I began crafting an on-list reply, only to find I had nothing substantive to add. Then I began writing a private message, only to discover that perhaps this still makes interesting discussion. Now I'm thinking we may be on to something here that actually applies directly to the original post. I think we're on the same page practically speaking, but not didactically. That is, given a concrete design problem, we'd come to similar conclusions; but we're taking opposite approaches. Kripa was looking for general reasons to avoid eval() or to be careful when using eval(). So we start talking about code fragments in which eval() doesn't apply. To my mind, that immediately implies a number in which it does. Or to put it another way, if I misuse eval(), that's not eval()'s fault; it's mine. To my mind, that's no reason to avoid the language feature; rather, that's a reason to understand the language feature before using it (as one ought any language feature). To compare, some say we should avoid Perl because it allows us to write messy, dense code. Yeah, so? It also allows us to design concise, elegant solutions quickly. /But then,/ the argument goes, /no one else can understand that code./ Roll-eyes. And by the same token, just because you can write code that doesn't work using eval() in ways that would confuse someone who doesn't have the perldocs handy, that's a poor reason to avoid eval() in general. You can place the blame wherever you want to. But with a more capable version of eval, you can make the proposed design work. To my mind, it's not about blame. Rather, it's about designing elegant software that works. And if eval() doesn't do what we want in a given situation, we use something that does work. The greater danger is writing code that works but is fragile. So in that sense, maybe we can indeed add another item to Kripa's list: * context confusion eval() executes in the context in which it's called, not the context in which the code string is assembled. So if these two are different, be sure your code is clear about which context the eval()'ed code sees. Otherwise, one might be misled, thinking the wrong set of variables are being accessed, and inadvertently introduce bugs. Other stuff: The problem is that the place where you'd like to centralize the code manipulation, calling eval, catching errors etc is in one place, and the code that you'd like to manipulate is in another... I guess I don't understand the design requirements. It sounds potentially like an interesting design challenge. But I think you'd have to nail down the requirements a little more. Note that $generator... It is not a coroutine. I finally looked it up. You're right. One of these days my mind will completely go, and about that time I'll be working on a highly classified, mission-critical project for the Defense Department and... -TimK ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] advocacy, et al.
Stephen A. Jarjoura wrote: ... now work in an almost totally Win2k/2k3 environment. In this setting, Perl isn't even considered a real programming language. It's referred to as scripting as opposed to programming, and while the developers program in ASP.NET, I only script in Perl. Interesting. But as Tom wrote, this sounds like it's a symptom of some broader political problem, hopefully, few of us have to face. Perl as a scripting language: I've written Perl scripts and I've written full-blown, object-oriented Perl apps. The difference is merely one of scale, not of type. If you develop an involved enough script, it's real programming (so-called), no matter what language you do it in. I've written quick-and-dirty Perl programs that grew up to be whole systems. One of the advantages of Perl--and I know some other languages can also do this--is that it can usually scale with such projects. -TimK -- J. Timothy King ..team-oriented..object-oriented..Agile.. www.jtse.com ..C++..Perl..Java..assembly..embedded.systems.. ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
