Re^2: Something to meditate on -- the need for a trendy perl?

Replies are listed 'Best First'.
Re^3: Something to meditate on -- the need for a trendy perl? by zentara (Cardinal) on Mar 12, 2014 at 13:43 UTC
I stand corrected, especially for C++, but I still think of them being more OO than C or Perl. From: everything is an object in Python : "This is so important that I'm going to repeat it in case you missed it the first few times: everything in Python is an object. Strings are objects. Lists are objects. Functions are objects. Even modules are objects. " I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]
Re^4: Something to meditate on -- the need for a trendy perl? by Arunbear (Prior) on Mar 12, 2014 at 17:05 UTC
Yes, everything in Python is an object, but the language does not force you to code in the OO style (unlike e.g. Java). Perl's object system was 'borrowed' from Python, so e.g. in both languages instance methods are just functions that take 'self' as the first parameter to access the object's state: `# Perl sub get_name { my ($self) = @_; return $self->{name}; } # Python def get_name(self): return self.name` [download]	[reply] [d/l]
Re^5: Something to meditate on -- the need for a trendy perl? by perl-diddler (Chaplain) on Mar 12, 2014 at 19:03 UTC
Given the timing of the two -- python coming out in 91 -- it just wasn't that popular yet to have had a strong influence... but C++ has the same paradigm -- passing 'this' as the first param on the stack... Yet, how else would one do it where objects can have variable params. Is there a language that does it differently? While I hadn't heard of python back in 91, I was using perl4. Perl5 came out in 94, 3 years later. While it could have been influenced by python, what other paradigm is there? I'd see both python and perl having derived such from C++, but maybe you were part of the design team and know something more from personal history? C++ had been around since the early-mid 80's and was already fairly well known and used (I'd used it, but integrating obj paradigms is still an ongoing work for me). So it seemed a more logical influence. Given perl's roots, I didn't give lisp much credit even though perl is closer to lisp than python... If perl came from python, I'm surprised perl's obj system is so much more flexible (as others have compared it to lisp). I'll bet that lisp passed the "this" object as the first list param as well...(?)...	[reply]
Re^6: Something to meditate on -- the need for a trendy perl? by tobyink (Canon) on Mar 13, 2014 at 23:42 UTC
Re^3: Something to meditate on -- the need for a trendy perl? by LanX (Saint) on Mar 12, 2014 at 14:28 UTC
Pythonistas like to claim having a multi-paradigm language and right in the next phrase they'll tell you that there shouldn't be more than one way to do it. Perl for instance is far closer to LISP, lambdas (anonymous subs) are not restricted to one statement and Perl's `my` is provides a declaration like LISP's `let` lacking in Ruby, Python and to some extent even in JS. I had the privilege to see a presentation of a Python module which was a port from Ruby, and it's almost ridiculous to see how they try to circumvent the limitations of their syntax to be able to reflect real lamdas ("code-blocks" in Ruby). Cheers Rolf ( addicted to the Perl Programming Language)	[reply] [d/l] [select]
Re^4: Something to meditate on -- the need for a trendy perl? by Arunbear (Prior) on Mar 12, 2014 at 18:18 UTC
But they do have let and lambdas, and even macros :)	[reply]
Re^5: Something to meditate on -- the need for a trendy perl? by LanX (Saint) on Mar 13, 2014 at 01:24 UTC
hehe! xD Well you know at the end of this talk Guido recommends to use precompilers for such new features. Cheers Rolf ( addicted to the Perl Programming Language)	[reply]