Not trying to beat a dead thread but I wanted to belatedly thank everyone for their insightful responses.
-- David On Mon, Jul 29, 2013 at 2:02 PM, John Redford <[email protected]> wrote: > Tom Metro wrote: > > John Redford wrote: > > > Perl's popular origin was based on its operation as a tool that glued > > > together the functionality (not the code) of existing tools like sed, > > > grep, find, sort, sh, and so forth. > > > > This is all true, and yet utterly irrelevant. If you look into the > historical origin of many languages you will find an initial purpose that > its > > current use has greatly diverged from. > > It's not "utterly irrelevant". The point is, Perl still does well the thing > it was mainly intended to do. Perl could do much worse than being an > intrinsic part of UNIX. > > > > Also, any time I hear Perl advocates talking about how dynamic typing > > > is better than static typing, it just reminds me that Perl doesn't > > > have type inference. > > > What do you see as the advantage to type inference over dynamic typing? > > The obvious one seems to be that it lets you emulate dynamic typing in a > statically typed language by doing all the dynamic typing > > determination at compile time, and thus better efficiency. > > No... cause inference doesn't do that. A lot of Perl's "dynamic typing" is > only interesting around the built-in scalar types -- i.e. strings & numbers > -- which is more related to the syntactic sugar of string concatenation in > other languages. > > Perl: $x = 5; $y = "foo" . $x; > Java: x = 5; y = "foo" + x; > > In both cases you get the string "foo5", because of some automatic > conversion stuff (boxing/toString) that's "nice" from the perspective of an > old-school C programmer, but basically taken-for-granted by everyone else. > Type inference comes into play with other things, like method calls: > > Perl: $x = foo(); $y = $x->bar(); > Xtend: x = foo(); y = x.bar(); > > Here Xtend can see what the type returned by foo is and determine if that > type even has a bar method to be called. There's nothing "dynamic" going on > in either language -- in theory Perl might dynamically AUTOLOAD a bar > method, but that's not going to help if you've written the wrong thing in > the first place, and it seems to be highly discouraged these days, though I > think it's a great feature of Perl which I'd want to have in some other > contexts. > > The "big" advantage of this is that you never mention types other than > where > they _must_ be mentioned, thus making those points in the code more visible > -- one of the many examples of how "readable code" benefits from having > less > code to have to read. Changing types becomes relatively easy -- change it > in > one place and it trickles to the others without a lot of typing (the > click-click kind). > > > How often do you run across cases where the compiler infers incorrectly? > > "Incorrectly" is basically impossible. "Too broadly" is possible, but > that's the same as it being an error to be fixed -- say you have code like > this: > > def foo () { > return if ( x ) new Abc() else null > } > > This infers to "Object", because that's the common super-type of Abc and > null. There are a lot of ways to fix it, like "null as Abc" to explicitly > cast the null to Abc. The point is, it would mean an error elsewhere in > code > where you're writing this: > > x = foo(); y = x.bar(); > > Because the inferred type would be "Object", and "Object" doesn't have the > method "bar", so you get a compile-time error. > > > Doesn't it defeat the purpose of choosing a statically typed language? > > The whole idea is just to do less physical (click-click) typing, and not > write things the compiler can figure out on its own. It just needs you to > specify types where they originate, and then make sure your usage is > appropriate based on the flow of the data. > > > > Of course, the substantial problems of Perl are intractable. One > > > cannot fix them without changing Perl into a completely different > > > language -- even if one maintained backwards compatibility, there > > > would be a serious question of why one would bother to do so. > > > > > > ...there is not much you can take away from the language and still > > > call it Perl. > > > > Now if only there was a language that was shiny and new, leapfrogged the > other dynamic languages with innovative design, all while > > incorporating the spirit and flavor of Perl, so former Perl developers > would largely embrace it.... > > > > Oh yeah, Perl 6. > > Perl6 may or may not become popular with the Perl Community... but it would > be just as easy to rename C# to "Perl7" and tell the Perl Community "this > is > the new Perl". It has more to do with who is telling them than with what is > being said. > > > When Perl 6 for hit the scene, I don't think enough Perl developers were > ready to jump ship to it, even if it had been production ready. > > Now that it is finally getting close to being usable, is it still > innovative, or more on parity with the competition? > > It's been a while since I've reviewed the features of Perl6, but I still > don't see anything very interesting there in terms of practical value or > even novelty -- it wasn't novel when it was new. In 1992 Annika Aasa wrote > a > thesis 'User Defined Syntax' (ISBN 91-7032-738-6), which covered the > subject > of a language which extends its own syntax very clearly -- around that time > I wrote a toy implementation of his approach in C. It's not exactly new... > it is somewhat "cool", but it's just not that useful in practical code. > (Reflect on how little a similar degree of expressive power did to help the > popularity of m4.) > > Of more modern and practical value one finds the Eclipse Modeling > Framework, > which permits one to create languages, generate code, integrate with IDEs, > connect code to proof/correctness/testing/visualization/specification > systems and generally do much more complicated, powerful and useful things > than Perl6 promises to deliver on a good day. > > As I see it, Perl5 made it possible for developers (per se) to write > large/complex/real programs without (generally) any deep understanding of > what they were doing and without encouraging them to know. And Perl6 > promises (or threatens) to give those same people more complicated and > powerful tools without changing their underlying philosophical approaches > of > one-language-ism and don't-look-under-the-hood-ism. Like 'User Defined > Syntax' it's a fascinating -- apparently entrancing -- prospect... but > there's very little "win" in it. > > In the time that Perl6 still hasn't-yet-existed, embedded XML support was > added to both VB.NET and JavaScript. Sure, it might be great for a > programmer to write their own embedded syntax... but embedded XML addresses > roughly 95% of the problem space. If I want that last 5% I can write a > little parser, target JVM/EMF or .NET, and get the benefits of the other > 95% > still interoperating... Perl6 just can't offer that -- or even come close. > > > > _______________________________________________ > Boston-pm mailing list > [email protected] > http://mail.pm.org/mailman/listinfo/boston-pm > _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
