Perl or Python

Sergei Steshenko · 02-25-2013, 11:16 PM

Quote:

Originally Posted by mina86

My second translation does what you want. ...

Where is that second translation ?

devUnix · 02-26-2013, 12:04 AM

Quote:

Originally Posted by sundialsvcs

Personally, I use Perl and Python (and... and...) pretty much interchangeably in my line of work, so I honestly don't think too much about them and certainly don't try to debate philosophies or to suggest that one is "better than" another. It also simply isn't the point of "what can one do that the other cannot."

There are various articles such as http://www.norvig.com/python-lisp.html and http://openbookproject.net/py4fun/lisp/lisp.html which are much better than I am at discussing the etymology of the various programming languages (and, mind you, they definitely do each have one).

In my view, you can definitely see a Lisp influence in Python, with its use of tail-recursion, S-expressions and a bunch of other funky ideas. Not so much in Perl, which was inspired by Awk.

There are always multiple "levels of

" in every programming language. There's a friendly, approachable front-room that you can spend a lot of time in, perhaps an entire career in. But, over there in the corner, not drawing attention to itself in any particular way, there is a little Door. If you choose to open that door, a strange and intoxicating odor will waft out. You can follow it, exploring the first Hall of Mysteries. At the far end of that room, also not drawing attention to itself, is another little Door ...

You will generally not find the differences between various languages in that friendly, approachable front room.

Every programming language, without exception, started in the mind of some person (or, eecch! committee) who had a problem to solve and who envisioned an "–er" tool to solve that problem and others like it. Then, a whole bunch of other people whacked on it over the years, and wrote a lot of code in it which paid for their research-grants and salaries. And, so it goes.

Thanks for sharing your insight!

mina86 · 02-26-2013, 08:30 AM

Quote:

Originally Posted by Sergei Steshenko

Where is that second translation ?

#28, read after “UPDATE”.

Sergei Steshenko · 02-26-2013, 09:25 AM

Quote:

Originally Posted by mina86

#28, read after “UPDATE”.

OK, so could you separate your code into two files ? Doing that will hopefully show yet another inherent problem.

mina86 · 02-26-2013, 11:41 AM

Quote:

Originally Posted by Sergei Steshenko

OK, so could you separate your code into two files ? Doing that will hopefully show yet another inherent problem.

Spare me, and just tell my what you think is an inherent problem.

If the problem is that the main module will be able to overwrite createCar from the second module, than this is not a problem, no matter how much you'd like it to be. In fact, it's a feature which makes testing possible. Your Perl code is untestable since unit tests cannot substitute the car creation routine with some other routine which returns a mock object.

Sergei Steshenko · 02-26-2013, 09:55 PM

Quote:

Originally Posted by mina86

Spare me, and just tell my what you think is an inherent problem.

If the problem is that the main module will be able to overwrite createCar from the second module, than this is not a problem, no matter how much you'd like it to be. In fact, it's a feature which makes testing possible. Your Perl code is untestable since unit tests cannot substitute the car creation routine with some other routine which returns a mock object.

I know Python very superficially, that's why I only suspect what the problem is. If and when those who know it well implement the task according to their understanding of Python, and if the problem I suspect is indeed there, we'll discuss it. If not - I am wrong in my suspicions.

mina86 · 02-27-2013, 08:02 AM

Quote:

Originally Posted by Sergei Steshenko

I know Python very superficially, that's why I only suspect what the problem is. If and when those who know it well implement the task according to their understanding of Python, and if the problem I suspect is indeed there, we'll discuss it. If not - I am wrong in my suspicions.

For crying out loud, here you are:

Code:

$ cat car.py

def createCar(color, power):
    …
$ cat main.py
import car

fancy_car = car.createCar(…)
humble_car = car.createCar(…)

…

Sergei Steshenko · 02-27-2013, 08:55 AM

Quote:

Originally Posted by mina86

For crying out loud, here you are:

Code:

$ cat car.py

def createCar(color, power):
    …
$ cat main.py
import car

fancy_car = car.createCar(…)
humble_car = car.createCar(…)

…

So, again, namespace pollution ?

I.e. the 'car' name pollutes top level namespace, correct ? ... Was it, by the way, 'Car' rather than 'car' ?

If yes, you see yet another source of potential errors ?

You need to know the class name, don't you ? You probably need the files to follow <class_name>'py naming convention ?

mina86 · 02-27-2013, 10:41 AM

Quote:

Originally Posted by Sergei Steshenko

So, again, namespace pollution ?

No.

Quote:

Originally Posted by Sergei Steshenko

I.e. the 'car' name pollutes top level namespace, correct ? ... Was it, by the way, 'Car' rather than 'car' ?

No. It's “car” as in the name of the module defined in car.py file. It does not pollute top level namespace any more than $create_car = require 'create_car.pl'; does. All variables defined in separate files reside in their own namespaces. import is not include.

By the way, either of the below will work as well:

Code:

import car as blah
fancy_car = blah.createCar(…)

Code:

from car import createCar
fancy_car = createCar(…)

Code:

from car import createCar as blah
fancy_car = blah(…)

Quote:

Originally Posted by Sergei Steshenko

If yes, you see yet another source of potential errors ?

No, so no.

Quote:

Originally Posted by Sergei Steshenko

You need to know the class name, don't you ?

I do, so?

Quote:

Originally Posted by Sergei Steshenko

You probably need the files to follow <class_name>'py naming convention ?

No.

So, have we established already that your argument is invalid?

Sergei Steshenko · 02-27-2013, 11:12 AM

Quote:

Originally Posted by mina86

No.

No. It's “car” as in the name of the module defined in car.py file. It does not pollute top level namespace any more than $create_car = require 'create_car.pl'; does. ...

Of course, yes.

Module names are in global namespace in both Perl and Pyhton, while top level lexical variables are not.

Furthermore, and I think it's the fundamental issue Python proponents do not understand, with anonymous export -> named import, i.e. with

Code:

my $foo = require 'some_file.prl';

idiom it is the consumer (the human) who decides on in this case '$foo' name; in other words, it's the consumer who performs name binding as late as possible, and because the producer of 'some_file.prl' exports just an anonymous reference, no namespace pollution occurs - by construction.

With

Code:

my $foo = require 'some_file.prl';

idiom provided neither side uses global namespace neither consumer can pollute 'some_file.prl', nor producer can pollute 'main.pl'. The interpreter simply doesn't present such a possibility - by construction.

...

Maybe I'll prepare a shorter example showing lack of protection of variables in producer. And maybe even in consumer - I have to check Python documentation and maybe even write some code myself.

mina86 · 02-27-2013, 12:01 PM

I'm seriously getting tired of this argument. Granted, in

Code:

my $foo = require 'file.prl';

consumer decides on the name of $foo but that's also true in case of:

Code:

import file as foo

Now, can we finally agree that your argument has no merit?

Sergei Steshenko · 02-27-2013, 12:25 PM

Quote:

Originally Posted by mina86

I'm seriously getting tired of this argument. Granted, in

Code:

my $foo = require 'file.prl';

consumer decides on the name of $foo but that's also true in case of:

Code:

import file as foo

Now, can we finally agree that your argument has no merit?

Then we have another problem - we need to make sure that 'file' module has 'file.py' file name.

I am saying that

give_name_to_anonymous foo_name

is simpler than

rename foo bar
.

Or in yet other words - why to have a name if it is to be discarded anyway ?

And AFAIR, in ( http://docs.python.org/release/2.5.2/ref/import.html )

Quote:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

the "as" part wasn't originally there, but I'm not sure - I seriously looked into Python in year 2000.

mina86 · 02-27-2013, 12:33 PM

Quote:

Originally Posted by Sergei Steshenko

rename foo bar

You don't have to rename files. You just import it under a different name.

Quote:

Originally Posted by Sergei Steshenko

Or in yet other words - why to have a name if it is to be discarded anyway ?

Because files have names… I'm sorry, I don't know how to answer that. It's like asking why the Perl file has “car.prl” name if you are discarding it.

Quote:

Originally Posted by Sergei Steshenko

the "as" part wasn't originally there,

So?

Sergei Steshenko · 02-27-2013, 01:23 PM

Quote:

Originally Posted by mina86

You don't have to rename files. You just import it under a different name.

Because files have names… I'm sorry, I don't know how to answer that. It's like asking why the Perl file has “car.prl” name if you are discarding it.

So?

I didn't mean renaming files.

I meant that when writing first the producer gives a name, and then the consumer renames that name in

Quote:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

construct.

So why giving name in the first place ?

And, overall, this example shows that in order to imitate block scope classes are used, and classes require names, and the name is then discarded.

Readable ? Logical ?

By the way, in Java scopes also used to suck, and the workaround was also to use classes, and classes could be anonymous, but 'class' keyword was needed.

I suspect Java designers wanted to make Java as different from C++ as possible, and Python designers wanted to make Python as different from Perl as possible.

Ironically, both Java and Python designers in the end had to introduce closures.

...

Quote:

So

- first Python designers introduce a problem by not having anonymous export, then they compensate for the problem introducing 'import module as name'. So you see, how much activity ? In Russian we say "имитация кипучей деятельности" - aka ИКД - "imitation of boiling activity" - "boiling" means intensive.

ntubski · 02-27-2013, 02:08 PM

Quote:

Originally Posted by Sergei Steshenko

I didn't mean renaming files.

I meant that when writing first the producer gives a name, and then the consumer renames that name in

Code:

import_stmt ::= "import" module ["as" name] ( "," module ["as" name] )*

construct.

So why giving name in the first place ?

The module name before the "as" is really in the filesystem namespace (like 'foo.pl' except that it can look for "foo.py" or "foo.pyc"), it doesn't go in the consumer's namespace:

Code:

>>> import foo as bar
>>> foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined
>>> bar
<module 'foo' from 'foo.py'>