If you're interested in PDL, you shoud also be keeping an eye on Perl6 and Parrot, which frm what I've seen look to be incorporating PDL ideas into the base implementation.
Whatever 64-bit PPC CPU Apple ends up with, be it from IBM, Motorola, or a new partner like AMD or nVidia, will almost certainly have to natively run 32-bit code.
When we talk about the advantages of different languages, how much of the time are we talking about the language, and how much is about the tools?
I mean, when I've played with OS X programming in Obj-C, I know that Cocoa apps could be written in Eiffel or Ada or any number of other languages. But the tools don't support these languages, and the tools make things so unbelievably easy.
Perl 6 is hardy convulsing. It's actually coming along quite nicely.
It also has the advantage of being a fresh start(it behaves much like Perl 5 in everyday use, but for different, better, more consistent reasons). Python is a wonderful language, but that doesn't have to mean Perl can't be a great language too.
Yes, but not everything behaves as one would expect an object too, leading objects of certain classes to behave as primitives. Unless there's been quite a bit of type/class unification progress made, I don't believe you can subclass some of the more basic(and useful!) objects either.
In this respect Ruby has both languages(at least until Perl6) beat.
I'm not saying they're exactly the same, but I do think they're more similar than most people like to think.
Not really. Syntactically they are different, and Python certainly has some conveniences(named parameters come to mind as a big one), but the underlying ideas are not incompatible.
Both actually have remarkably similar approaches and capabilities with regard to object-oriented programming(this in terms of Perl 5).
Python's functional programming ideas can fairly easily be translated to Perl constructs such as map and grep.
Not sure how easily generators would translate to Perl, as I've not had occasion to use them yet.
If you try to have two modes, the developers will simply focus on the "advanced" mode and neglect the "simple" mode. The advanced mode quickly would become the only usable alternative, and you're back to the drawing board.
What I think you're missing is that "advanced" does not mean having control over every single widget's appearance. It means having control over things that actually add functionality to the interface.
And no, adding half a dozen ways to do the same thing does not equate to adding functionality.
I see it rather the opposite way. If such a thing were to happen at all, the 3 button mouse would more likely take the "Pro" name and the one button(realy in a way "no button") mouse would fall into the consumer arena.
That said, a multi-button mouse would take a lot of design work, given Apple's clear design goal of not exposing moving parts. To this end, a solid-state scroll wheel inspired by the new iPod would probably be quite a nice addition. Perhaps a side to side rocing motion could complement the forward wrist motion to produce three "clicks".
How many people still play Tetris, or original Nintendo games?
A lot of people do. Just because a game has been in existence for 3 years doesn't mean anyone, aside from hard-core gamers who go through a new game each night, is necessarily tired of it.
Parrot 0.0.7 was released last night. It contains a very rudimentary first Perl6 compiler, based on the Perl6 grammar by Sean O'Rourke, and Melvin Smith's IMCC intermediate language.
Perl 6 is your language then. You won't be able to directly use it in shell scripts, but once you have Perl figured out, you won't mind that anyway.;-)
Having whitespace be insignificant by default should help a great deal with readability, as will the efforts to make regex syntax more consistent. The ability to embed Perl 6 objects into regular expressions should also lead to some interesting developments.
Actually, I'm just beginning to dip my toes into the Scheme/Haskell/*ML waters. It doesn't help that most of the compilers are a pain to install on Mac OS X.
I've found closures can be genuinely useful for complex looping behaviors that are used repeatedly throughout a program.
Well.... I started with HTML and Javascript, then moved onto some very basic Perl at the urging of a friend, and did some pretty complex(and really stupid!) things with flat-file databases.
At the urging of the same friend I learned Python, and grew to like it rather quickly as it helped me understand OO concepts.
I later moved onto Ruby, and for various reasons was alternating between the two languages heavily when I registered my username.
Since, in the excitement that Parrot has provided - it's the first time I haven't been "catching up" on something - I've returned to my Perl beginnings, doing it right this time around.
You'd be amazed the amount of programming theory you can soak up reading through the perl6 mailing lists.:-)
When I help friends with picking up Perl, I generally start by emphasizing the separation of interface and implementation in a program, the go over basic I/O, then variables, then subroutines, then aggregate and nested data structures, then objects. All of the different control structures(conditionals, loops, etc.) are gradually covered in the context of building a trivial sample class. I save things like closures for a bit later, as I don't like to mix the "here's a data structure with access to some subroutines", and "here's a subroutine with access to some persistent data" messages.
This is very easy for Perl to figure out, and can be optimized. A general loop, however, is much much harder for the bytecode compiler to optimize, since it introduces far greater potential complexity. The more concisely you can say something, the fewer different ways it can be taken.
A lot of the things that look ambiguous in Perl are in fact quite the opposite to the compiler/runtime. Using such things when appropriate is a good idea even in large projects.
Perl 6 should help quite a bit, as well. Optional strong typing, and a proper OO facilities. I even made a comment on the mailing list that it might be worth investigating whether or not Perl 6 could transcend the simple public/private/protected scheme and do something along the lines of Eiffel. Say...
class Hello {
method world is public {
print "Hello world!\n";
}
method foo is public(Bar) {
print "Hello foo!\n";
} }
class Foo {
method main {
Hello.new.foo;
# throws an exception since
# method foo of class Hello
# is private to class Foo
} }
The other plus is that I have my downloads go to a folder in my home directory, rather than the Desktop to keep things clean, but then I can mount the disk image and it's easily accessible on the Desktop, without having to open a Finder window to get at it.
You can write bad code in any language, and no language particularly encourages good coding practices. The only exceptions I can think of off the top of my head are Eiffel(http://smalleiffel.loria.fr), and perhaps Ada.
It isn't the job of a language syntax to make someone a good programmer. That's the job of the person teaching them. If it's that big a problem, get into the newbie communities and instill good practices from the very beginning.
Spend more time coding than reading books about coding. Experiment with other languages than just Perl. I know I had to learn Python, or at least aggressively dabble in it, before some of the more advanced Perl concepts made even the slightest bit of sense.
You don't have to go to college to be a good programmer. For some people it helps, but it isn't necessary.
I take it you're unaware that Perl 5 allows for modular, object-oriented code?
{
package Foo;
sub new {
my $class = shift;
return bless {@_}, $class;
}
sub bar {
my $self = shift;
if (@_) {
$self->{bar} = shift;
}
return $self->{bar};
} }
my $foo = new Foo(bar => "hello world!"); print $foo->bar; # hello world!
See, that wasn't so hard.
And in some ways the underlying approach is little different that Python's(and PHP's... I think) much vaunted object model. OO code in C functions in much the same way as well. In all of them the object itself is the first argument passed to the function/subroutine, and syntactic sugar allows this to happen automagically.
Slashdot Mirror
A comparison could be made. Install OS X on a Mac of some type, then install Windows Xp via VirtualPC.
If you're interested in PDL, you shoud also be keeping an eye on Perl6 and Parrot, which frm what I've seen look to be incorporating PDL ideas into the base implementation.
Whatever 64-bit PPC CPU Apple ends up with, be it from IBM, Motorola, or a new partner like AMD or nVidia, will almost certainly have to natively run 32-bit code.
Mac OS X already takes advantage of multiple processors. Think Xserve and the dual processor PowerMacs.
When we talk about the advantages of different languages, how much of the time are we talking about the language, and how much is about the tools?
I mean, when I've played with OS X programming in Obj-C, I know that Cocoa apps could be written in Eiffel or Ada or any number of other languages. But the tools don't support these languages, and the tools make things so unbelievably easy.
So is it the tools, or is the language/runtime?
Perl 6 is hardy convulsing. It's actually coming along quite nicely.
It also has the advantage of being a fresh start(it behaves much like Perl 5 in everyday use, but for different, better, more consistent reasons). Python is a wonderful language, but that doesn't have to mean Perl can't be a great language too.
Nice!
I've apparently been out of the loop a little too long.
Yes, but not everything behaves as one would expect an object too, leading objects of certain classes to behave as primitives. Unless there's been quite a bit of type/class unification progress made, I don't believe you can subclass some of the more basic(and useful!) objects either.
In this respect Ruby has both languages(at least until Perl6) beat.
I'm not saying they're exactly the same, but I do think they're more similar than most people like to think.
Not really. Syntactically they are different, and Python certainly has some conveniences(named parameters come to mind as a big one), but the underlying ideas are not incompatible.
Both actually have remarkably similar approaches and capabilities with regard to object-oriented programming(this in terms of Perl 5).
Python's functional programming ideas can fairly easily be translated to Perl constructs such as map and grep.
Not sure how easily generators would translate to Perl, as I've not had occasion to use them yet.
Well, that was just a thought. And this explains why I am not a highly paid hardware designer.
If you try to have two modes, the developers will simply focus on the "advanced" mode and neglect the "simple" mode. The advanced mode quickly would become the only usable alternative, and you're back to the drawing board.
What I think you're missing is that "advanced" does not mean having control over every single widget's appearance. It means having control over things that actually add functionality to the interface.
And no, adding half a dozen ways to do the same thing does not equate to adding functionality.
"iMouse"?
I see it rather the opposite way. If such a thing were to happen at all, the 3 button mouse would more likely take the "Pro" name and the one button(realy in a way "no button") mouse would fall into the consumer arena.
That said, a multi-button mouse would take a lot of design work, given Apple's clear design goal of not exposing moving parts. To this end, a solid-state scroll wheel inspired by the new iPod would probably be quite a nice addition. Perhaps a side to side rocing motion could complement the forward wrist motion to produce three "clicks".
How many people still play Tetris, or original Nintendo games?
A lot of people do. Just because a game has been in existence for 3 years doesn't mean anyone, aside from hard-core gamers who go through a new game each night, is necessarily tired of it.
Parrot 0.0.7 was released last night. It contains a very rudimentary first Perl6 compiler, based on the Perl6 grammar by Sean O'Rourke, and Melvin Smith's IMCC intermediate language.
Python's re.py module also allows for escaping characters that have meaning in regular expressions, for what it's worth.
Perl 6 is your language then. You won't be able to directly use it in shell scripts, but once you have Perl figured out, you won't mind that anyway. ;-)
Having whitespace be insignificant by default should help a great deal with readability, as will the efforts to make regex syntax more consistent. The ability to embed Perl 6 objects into regular expressions should also lead to some interesting developments.
That's merely a side-effect of the $ sigil, whose primary purpose is to effectively put variables and functions into separate namespaces.
Actually, I'm just beginning to dip my toes into the Scheme/Haskell/*ML waters. It doesn't help that most of the compilers are a pain to install on Mac OS X.
I've found closures can be genuinely useful for complex looping behaviors that are used repeatedly throughout a program.
Well.... I started with HTML and Javascript, then moved onto some very basic Perl at the urging of a friend, and did some pretty complex(and really stupid!) things with flat-file databases.
:-)
At the urging of the same friend I learned Python, and grew to like it rather quickly as it helped me understand OO concepts.
I later moved onto Ruby, and for various reasons was alternating between the two languages heavily when I registered my username.
Since, in the excitement that Parrot has provided - it's the first time I haven't been "catching up" on something - I've returned to my Perl beginnings, doing it right this time around.
You'd be amazed the amount of programming theory you can soak up reading through the perl6 mailing lists.
When I help friends with picking up Perl, I generally start by emphasizing the separation of interface and implementation in a program, the go over basic I/O, then variables, then subroutines, then aggregate and nested data structures, then objects. All of the different control structures(conditionals, loops, etc.) are gradually covered in the context of building a trivial sample class. I save things like closures for a bit later, as I don't like to mix the "here's a data structure with access to some subroutines", and "here's a subroutine with access to some persistent data" messages.
In fact, Perl does reward quick hacks. Consider:
print "$_\n" foreach @foo;
This is very easy for Perl to figure out, and can be optimized. A general loop, however, is much much harder for the bytecode compiler to optimize, since it introduces far greater potential complexity. The more concisely you can say something, the fewer different ways it can be taken.
A lot of the things that look ambiguous in Perl are in fact quite the opposite to the compiler/runtime. Using such things when appropriate is a good idea even in large projects.
Perl 6 should help quite a bit, as well. Optional strong typing, and a proper OO facilities. I even made a comment on the mailing list that it might be worth investigating whether or not Perl 6 could transcend the simple public/private/protected scheme and do something along the lines of Eiffel. Say...
class Hello {
method world is public {
print "Hello world!\n";
}
method foo is public(Bar) {
print "Hello foo!\n";
}
}
class Foo {
method main {
Hello.new.foo;
# throws an exception since
# method foo of class Hello
# is private to class Foo
}
}
The other plus is that I have my downloads go to a folder in my home directory, rather than the Desktop to keep things clean, but then I can mount the disk image and it's easily accessible on the Desktop, without having to open a Finder window to get at it.
You can write bad code in any language, and no language particularly encourages good coding practices. The only exceptions I can think of off the top of my head are Eiffel(http://smalleiffel.loria.fr), and perhaps Ada.
It isn't the job of a language syntax to make someone a good programmer. That's the job of the person teaching them. If it's that big a problem, get into the newbie communities and instill good practices from the very beginning.
Parrot is not a language, but rather a virtual machine that will act as a runtime environment for Perl6, Python, Ruby, Tcl, Scheme, etc.
Although I suppose you could be talking about Parrot assembly language.
Spend more time coding than reading books about coding. Experiment with other languages than just Perl. I know I had to learn Python, or at least aggressively dabble in it, before some of the more advanced Perl concepts made even the slightest bit of sense.
You don't have to go to college to be a good programmer. For some people it helps, but it isn't necessary.
I take it you're unaware that Perl 5 allows for modular, object-oriented code?
{
package Foo;
sub new {
my $class = shift;
return bless {@_}, $class;
}
sub bar {
my $self = shift;
if (@_) {
$self->{bar} = shift;
}
return $self->{bar};
}
}
my $foo = new Foo(bar => "hello world!");
print $foo->bar;
# hello world!
See, that wasn't so hard.
And in some ways the underlying approach is little different that Python's(and PHP's... I think) much vaunted object model. OO code in C functions in much the same way as well. In all of them the object itself is the first argument passed to the function/subroutine, and syntactic sugar allows this to happen automagically.
Foo::bar($foo) == $foo->bar;