Hi,
On 07.01.2017 15:52, Joseph Garvin wrote:
> Being able to type the elements in containers was considered a major
> problem in Java for years before they added generics.
Please note that Java and Perl 6 are coming from very different
directions. Java 1 a statically typed language, where every operation
whose type safety the compiler can't prove at compile time is rejected.
So with untyped containers in Java 1.4-, you needed explicit runtime
casts juts to call methods on container elements.
Perl used to be a dynamically typed language, which means that the
compiler basically never rejected a program due to type errors. Type
errors can happen at run time.
> And the whole
> point of having a computer is to have it do repetitive things, e.g. loop
> over a bunch of stuff and do the same thing to all of it.
You can loop over a bunch of stuff and do the same thing to all of it
without explicitly typing the contents of an array. That's what all
other dynamically typed languages tend to do (python, ruby, lua, PHP,
you name it).
If you have, for example:
sub wants-str(Str $x) { ...}
sub test(@a) {
for @a -> $x { wants-str($x) }
}
Perl 6 happily compiles and executes this, because it can't prove a type
error at compile time. Java OTOH would reject the equivalent code.
> How is this an
> "exaggerated" use of containers? Why have the language feature at all if
> it's too clunky for people to use it?
I'm not saying it's always too clunky to use. I'm saying there's a cost
attached, and you should consider whether to use it.
I observe some weird behavior in Perl 6 newbies (and I've observed it in
myself too): they're so enamored by type constraints that they use them
everywhere, and run into all sorts of type errors they didn't expect.
The weird part is that if they wanted a statically typed language, they
could have easily chosen one. But they picked Perl 6, and then they try
to use it like a statically language, and wonder why it feels clunky.
If you write a type constraint, ask yourself: could there be an object
from another type that my could would also work with? Maybe I'm just
calling a method that's implemented in type Str, but a user-supplied
object could implement the same method as well. If it walks like a duck,
and quacks like a duck, do I really have to care if it's a duck or not?
Cheers,
Moritz
--
Moritz Lenz
https://deploybook.com/ -- https://perlgeek.de/ -- https://perl6.org/
