Dots and Perl(perlhacks.com)
perlhacks.com
Dots and Perl
http://perlhacks.com/2014/01/dots-perl/
4 comments
The three-dots operator for not implemented code is a clever idea IMHO, if it was present in Ruby I would use it all the time :-)
Yeah, you can actually find many many clever little ideas in Perl 5 and 6. I even find reading the Perl 6 synopsis (http://perlcabal.org/syn/) entertaining.
The problem with Perl, IMO, is that there are too many clever ideas and it takes way too much to fit all of them together (and they never give up and ditch some of the less clever ones like Python people routinely do), which is why Perl6 is moving so slowly.
The problem with Perl, IMO, is that there are too many clever ideas and it takes way too much to fit all of them together (and they never give up and ditch some of the less clever ones like Python people routinely do), which is why Perl6 is moving so slowly.
> The problem with Perl, IMO, is that there are too many clever ideas and it takes way too much to fit all of them together (and they never give up and ditch some of the less clever ones like Python people routinely do), which is why Perl6 is moving so slowly.
I have to correct my statement about Perl6: it's not moving slowly, but it takes too much to get there.
I have to correct my statement about Perl6: it's not moving slowly, but it takes too much to get there.
A bit of both, actually.
Perl6 as an language is remarkably complete. http://perl6.org/compilers/features
Its performance has been absolutely terrible though. They've been (rightly) focused on features first.
But note that Perl6 on JVM is doing very well. I believe the effort is about a year old, and they've been performance optimizing it for a fraction of that time. And that's with nearly all of the 'remarkably complete' features.
https://github.com/rakudo/rakudo
Last time I did a benchmark a few months ago, Perl6 on JVM was very roughly 2x slower than Perl5. With Perl6's native but optional typing, I fully expect that Perl6 on JVM will get even faster than Perl5.
This year, I need to evaluate a 'scripting' language to run inside of big Java processes, and I'm going to give Perl6 a very close look.
Perl6 as an language is remarkably complete. http://perl6.org/compilers/features
Its performance has been absolutely terrible though. They've been (rightly) focused on features first.
But note that Perl6 on JVM is doing very well. I believe the effort is about a year old, and they've been performance optimizing it for a fraction of that time. And that's with nearly all of the 'remarkably complete' features.
https://github.com/rakudo/rakudo
Last time I did a benchmark a few months ago, Perl6 on JVM was very roughly 2x slower than Perl5. With Perl6's native but optional typing, I fully expect that Perl6 on JVM will get even faster than Perl5.
This year, I need to evaluate a 'scripting' language to run inside of big Java processes, and I'm going to give Perl6 a very close look.
Maybe too many clever ideas, but in the real world we evaluate a language for how is to use when you follow the coding standards etc. There really might be an initial extra cost of some work days, but unlike most people on HN I don't really know... :-)
Anyway, you can make a good argument for Perl with the best OO (Moose) of the scripting languages, CPAN (+ Testers, so it works), etc.
But please, no more of these language wars, it makes for really boring reading to e.g. see the same arguments whenever Perl is mentioned.
Anyway, you can make a good argument for Perl with the best OO (Moose) of the scripting languages, CPAN (+ Testers, so it works), etc.
But please, no more of these language wars, it makes for really boring reading to e.g. see the same arguments whenever Perl is mentioned.
> I even find reading the Perl 6 synopsis (http://perlcabal.org/syn/) entertaining.
The Operators page (http://perlcabal.org/syn/S03.html) scares me O.O
The Operators page (http://perlcabal.org/syn/S03.html) scares me O.O
I love Perl. Its flexibility and potential terseness are awesome, but there is something funny about a language that has the operator breadth of:
: :: .: .:: .. ... {...} .^ ..^ ^.. ^..^ ^^ , ;
And several of those have 2-3 uses. Heck, there's probably a way to use only those and some $'s and make something that runs.
: :: .: .:: .. ... {...} .^ ..^ ^.. ^..^ ^^ , ;
And several of those have 2-3 uses. Heck, there's probably a way to use only those and some $'s and make something that runs.
It's even crazier/cooler than that: https://metacpan.org/pod/release/BOOK/perlsecret-1.005/lib/p... -- lots of (mostly harmless/golf-oriented) fun with combining perl operators.
> The problem with Perl, IMO, is that there are too many clever ideas
Perl's learning curve is shallow (easy to pick up) but long (the language is big).
One explicit design goal from perl which isn't talked about much is "huffman coding" in the language. i.e. frequently needed language features should require fewer keystrokes.
This comes directly from Larry's background as a linguist. For example, English has the word "it" to mean "the thing we're talking about". Perl has "$_" to mean the same thing.
The meaning of "it" is dependent on the surrounding context. So it is with perl.
Similarly, it can be confusing to have long, runaway sentences using such context dependent words. You can write bad English and bad perl in this way if you're not careful.
However, the benefit is that, used correctly, it allows you to express yourself clearly and concisely.
Perl's learning curve is shallow (easy to pick up) but long (the language is big).
One explicit design goal from perl which isn't talked about much is "huffman coding" in the language. i.e. frequently needed language features should require fewer keystrokes.
This comes directly from Larry's background as a linguist. For example, English has the word "it" to mean "the thing we're talking about". Perl has "$_" to mean the same thing.
The meaning of "it" is dependent on the surrounding context. So it is with perl.
Similarly, it can be confusing to have long, runaway sentences using such context dependent words. You can write bad English and bad perl in this way if you're not careful.
However, the benefit is that, used correctly, it allows you to express yourself clearly and concisely.
In Scala 2.10 there is the ??? alias which throws a NotImplemented exception.
It's really nice for stubbing out code that otherwise needs to compile.
It's really nice for stubbing out code that otherwise needs to compile.
In pre-Perl 5.12 I've also implemented
I'm sure Ruby could do something similar. It may be less pretty but it works, and it is useful during certain types of development, I find.
sub not_impl {
die "Not implemented";
}
if ($some_clause) {
not_impl;
}
I'm sure Ruby could do something similar. It may be less pretty but it works, and it is useful during certain types of development, I find.
Indeed:
def not_impl(reason = 'unknown reason')
raise NotImplementedError.new reason
end
not_impl #=> NotImplementedError: unknown reason
not_impl 'TODO' #=> NotImplementedError: TODO
define_method("...") { raise NotImplementedError }
send "..." #=> NotImplementedError: NotImplementedError
It may be less pretty but it works...
The primary goal of the `...` feature was to make example code compile safely. (I implemented the feature in Perl 5.)
The primary goal of the `...` feature was to make example code compile safely. (I implemented the feature in Perl 5.)
Oh, yes, of course it doesn't do that, but it's still a useful thing. It's so short it hardly seems worth talking about, but, hey, I went a long time without using such a simple technique myself, so it probably is.
just b/c it's not a language feature doesn't mean that you can't make your own sort of thing. for instance, the play framework has a TODO result object that is indeed quite handy for stubbing out api endpoints and the like.
like the typed/untyped debate, the amount of primitives a language ought to have seems to be a topic of disagreement even among experts (touched on here http://www.infoq.com/presentations/functional-pros-cons although not the main topic). also, like type systems, primitives seem like something that, while important to consider, are easy to get hung up on, to take a stance and apply it to all languages without the consideration that different languages are good for different types of problems. my own snap judgements of perl were that its notions of context and pragmas make it easy to express one or two ideas both quickly and intuitively, but that its type system makes it difficult to reason about larger programs.
so to cap off this ramble, my question to the perl people: what problems are you solving with perl? to me, perl seems to mainly fit two use cases: sys-admin stuff (where it's basically used like bash++, although i realize it's much more powerful than that) and an embedded language for c programs.
like the typed/untyped debate, the amount of primitives a language ought to have seems to be a topic of disagreement even among experts (touched on here http://www.infoq.com/presentations/functional-pros-cons although not the main topic). also, like type systems, primitives seem like something that, while important to consider, are easy to get hung up on, to take a stance and apply it to all languages without the consideration that different languages are good for different types of problems. my own snap judgements of perl were that its notions of context and pragmas make it easy to express one or two ideas both quickly and intuitively, but that its type system makes it difficult to reason about larger programs.
so to cap off this ramble, my question to the perl people: what problems are you solving with perl? to me, perl seems to mainly fit two use cases: sys-admin stuff (where it's basically used like bash++, although i realize it's much more powerful than that) and an embedded language for c programs.
Perl is used heavily in biology and bio informatics. It's also really really good for messing with text in complicated ways. And it's still in use as a web language. So that's three more use cases.
I think you can think of it this way. ANSI C doesn't have a built in linked list, or hash/dictionary, or line count when reading a file, or map or grep or a bunch of things... and you can implement them (though map/grep are a bit tricky) but you have to worry about the implementation, and matching other people's implementation. By having the many useful primitives Perl does, it provides a broader standard interface for doing things, and that makes hacking easier.
Perl tries to give you lots of tools to express yourself. If you are a wood carver, you know that you can work wood with very limited tools, but having the right tool in your shop makes things a lot easier and simpler for the expert. So it is with Perl.
I think you can think of it this way. ANSI C doesn't have a built in linked list, or hash/dictionary, or line count when reading a file, or map or grep or a bunch of things... and you can implement them (though map/grep are a bit tricky) but you have to worry about the implementation, and matching other people's implementation. By having the many useful primitives Perl does, it provides a broader standard interface for doing things, and that makes hacking easier.
Perl tries to give you lots of tools to express yourself. If you are a wood carver, you know that you can work wood with very limited tools, but having the right tool in your shop makes things a lot easier and simpler for the expert. So it is with Perl.
yeah, i'm aware that perl is used by biologists, but the question is more like, "should perl be used by biologists?" no question that c is not a great choice, but what about python? or, hell, javascript, even? for the kind of programs biologists would want to write (i.e. programs that need to describe a system that performs several tasks rather than programs that need to perform one or two specific tasks), it'd be helpful to have a language that not only has data structures like arrays/lists and hashes/dictionaries but also a data model that includes things like classes as a primitive. python in particular has numpy/scipy.
perl's syntax for regexp matching definitely makes it a good choice for programs that have to do a lot of string-munging, but that's what i meant by "sys-admin-type stuff."
perl's syntax for regexp matching definitely makes it a good choice for programs that have to do a lot of string-munging, but that's what i meant by "sys-admin-type stuff."
Classes are not primitives in either language... primitives contain a value instead of a reference. I think you mean that classes are first order, but I don't want to put words in your mouth so perhaps you can clarify what the difference you are pointing to.
I think, given that Perl is being used, the question might be, what features make javascript or Python a good reason to switch? I'd want to avoid losing features.
Perl is stable. Perl written two decades or more ago still runs fine in modern perl. That's important for data analysis, especially in the sciences.
I'll have to read up on Python ... I'd want a tie equivalent to be able to treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.
I think, given that Perl is being used, the question might be, what features make javascript or Python a good reason to switch? I'd want to avoid losing features.
Perl is stable. Perl written two decades or more ago still runs fine in modern perl. That's important for data analysis, especially in the sciences.
I'll have to read up on Python ... I'd want a tie equivalent to be able to treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.
> I think you mean that classes are first order, but I don't want to put words in your mouth
please do. i'm a language user, not a designer.
> what features make javascript or Python a good reason to switch?
or, for a mostly-disinterested (in programming, i mean), entrenched group of users like biologists, this question becomes more like, "what features would necessitate a switch?" same question for plan 9 vs. linux or any technology that's trying to do a better job of filling a need that's already being met. ...and, of course, the answer is that there are none. perl has notions of object-oriented-ness. it's possible to build in your own type-checking. the backwards compatibility thing is definitely helpful for the sciences, and it's free, so, like the fortran routines that parts of numpy ultimately wrap, their code can live on.
i mentioned python and javascript not because i think they're such great languages but because i feel that they're in that position relative to perl. of course, unlike plan 9, python and javascript got a lot of users.
> treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.
not totally sure what you mean here. isn't that what databases are for?
anyway, for a new code base that's going to evolve a lot and possibly get scrapped entirely (i.e. most hn readers' situation), python is worth checking out.
please do. i'm a language user, not a designer.
> what features make javascript or Python a good reason to switch?
or, for a mostly-disinterested (in programming, i mean), entrenched group of users like biologists, this question becomes more like, "what features would necessitate a switch?" same question for plan 9 vs. linux or any technology that's trying to do a better job of filling a need that's already being met. ...and, of course, the answer is that there are none. perl has notions of object-oriented-ness. it's possible to build in your own type-checking. the backwards compatibility thing is definitely helpful for the sciences, and it's free, so, like the fortran routines that parts of numpy ultimately wrap, their code can live on.
i mentioned python and javascript not because i think they're such great languages but because i feel that they're in that position relative to perl. of course, unlike plan 9, python and javascript got a lot of users.
> treat large files as if they were arrays/hashs (lists/dicts) without loading them into memory as such.
not totally sure what you mean here. isn't that what databases are for?
anyway, for a new code base that's going to evolve a lot and possibly get scrapped entirely (i.e. most hn readers' situation), python is worth checking out.
In Perl you can do what numpy/scipy do with PDL, the Perl Data Language.
Perl is not just a string mangling language, it's a full-fledged generic programming language.
Perl is not just a string mangling language, it's a full-fledged generic programming language.
> my question to the perl people: what problems are you solving with perl?
Any problem, there are even 3d opengl games implemented in Perl.
Any problem, there are even 3d opengl games implemented in Perl.
Why would you need an operator for it? I just use assert False, with the TODO as message.
[deleted]
15 years of Perl and I just now learned about the yadda-yadda ... thanks!
It was introduced in v12: https://metacpan.org/pod/release/RJBS/perl-5.18.2/pod/perl51...
I had no idea about using a .. as a flip-flop, and I've been using perl for 15+ years.
It's stuff like this that makes writing perl like writing poetry. It's amazing how smoothly and with a minimum of friction you can jot down thoughts into code and have it work.