Slashdot Mirror

Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spe

Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spe

Version 1.1 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spec

Version 1.1 - Note: Features/bugs listed may not apply to some SCO products/versions

NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

Additional suggestions, detailed specific recommendations, comments, requested.

Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

In particular avoid these functions:

(please help with this list - "list 4")

Known bugs in SCO products:

Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

In particular don't depend on these compiler features:

(please help with this list if and when GCC loses SCO support)

6. Don't put in messages that display only on SCO's platforms.

Avoid putting in code like (and especially not commenting):

#if defined(_SCO_DS)
/* SCO OpenServer */ darlsux() ;
#elif defined(__UNIXWARE__)
/* UnixWare gcc */ darlsux() ;
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
#else
/* SCO UnixWare cc */ darlsux() ;
#endif
#elif defined(M_UNIX)
/* ODT 3 or earlier */
#else
/* Other platform */
#endif

7. Don't remove support in your makefile for building the application on SCO's platforms.

8. Don't rename your functions and variables with names that conflict with SCO-spec

I think Guido beat you to it.

I don't get to program much, since I have a day job, and to make matters worse, my formal training with computers was brief. Basically, I learned Python on public transport, communiting to and from work (the Python Cookbook causes people to turn their heads, by the way). I tried learning Java at one point, but the problem is that there are too many details and formalisms that you have to remember to even get anything off the ground.

Not so with Python. Basically, you just write what you want to code. Want to know if there are characters in a string?

if 'chocolate' in mystring:
....print 'I love it!'

(This is new in Python 2.3, and I can't get the indentation to work here). Fantastically intuitive.

The only "problem" is the way the library keeps growing from release to release: Something that you had to code yourself a while back suddenly is a trivial feature. More of an embarrassment of riches than a real problem, but it does make you feel like a fool sometimes. "Why code that socket server? Just use..."

One other nice thing about learning Python is how amazingly friendly and helpful their tutor list is. I've asked some amazingly stupid questions in my time, and they have been very gentle and kind.

Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Tkinter as tk
>>> root = tk.Tk()
>>> btn = tk.Button(root)
>>> btn.pack()
>>> btn.configure(text='Exit')
>>> import sys
>>> btn.configure(command=sys.exit)

>>> for a in dir(btn):
... print a
...
_Misc__winfo_getint
_Misc__winfo_parseitem
__doc__
[etc.]
winfo_width
winfo_x
winfo_y
>>>
>>> for key in btn.keys():
... print key
...
activebackground
activeforeground
anchor
[etc.]
underline
width
wraplength
>>>

That's what says in the link to the Python tutorial. It's quite good to get you to know the language and does not require a lot of previous programming experience. Then, the library reference can come very handy too.

That's what says in the link to the Python tutorial. It's quite good to get you to know the language and does not require a lot of previous programming experience. Then, the library reference can come very handy too.

The book starts with a chapter on building larger programs that covers @INC, eval, do and require before discussing packages and scope. It then has several chapters on references that explains in well understandable fashion and increasing complexity all the ins and outs of references including dereferencing, nested references, references to subroutines and references to anonymous data before a final chapter on references that gives you some incredibly useful tricks such as sorting and recursively defining complex data.

In other words, Perl needs a book devoted to topics that are totally straightforward in a well-designed language.

Hrm, interesting. After seeing this I went to the Python home page and found a document on this subject. After initially being overwhelmed with underscores, I tried to understand what was going on. It talked a lot about subclassing things like dictionaries, but I couldn't find anything about subclassing int and such.

Anyhow, I then fired up Python and said dir(1) and it gave me a list of methods. I then tried 1.__add__(2), and it didn't like it. Do I have the syntax wrong? If I do something equivalent in Ruby (1.methods, 1.+(2)) it works like I expect. I admit, I know Ruby much better than Python though so maybe it's just as easy in Python. Is there an easy way to do the equivalent of this in Python?

irb(main):026:0> class Fixnum; def distance_from_42; (self - 42).abs; end; end
=> nil
irb(main):027:0> 3.distance_from_42
=> 39
irb(main):028:0> 43.distance_from_42
=> 1

Anyhow, it's nice to see that Python is slowly becoming more Ruby-like. ;)

At least it doesn't consider whitespace syntaxtically significant!

Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.

Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.

Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

I think you should reserve judgement until there is an implementation. Otherwise sweeping statements like 'perl6 won't make development any faster' are pretty hard to justify or to disprove.

By all means attack perl5, or dismiss perl6 as vapourware.

FWIW, the huge ugly monster that is Mozilla seems to have turned out rather well in the end - it just took far too long to get there. It's not perfect, but it has succeeded in its own aims (be a portable web browser suited for everyday use).

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

To quote the Python 2.3 release page:

Nineteen months in the making, Python 2.3 represents a commitment to stability and improved performance, with a minimum of new language features. Countless bugs and memory leaks have been fixed, many new and updated modules have been added, and the new type/class system introduced in Python 2.2 has been significantly improved. Python 2.3 can be up to 30% faster than Python 2.2.

Python is indeed getting closer. Just give them some more years to finish the last three itens and suddenly we'll have thousands more using a Really Good language.

Note to moderators: this is a troll :-)

Booleans were added sometime in 2.2... 2.2.2 I believe. But yes, very handy. :)

2.2.1 added True and False constants, which were set to integer 1 and 0.
But 2.3 adds a true Boolean type.

Sounds like a Vlassic picle. More crunch.

At the top of the list of new features they have sets. The first paragraph says that sets are implemented by hashtables. I wonder whether it is really meaningless from the "practical" point of view to implement sets with data structures like red-black trees or Fibonacci heaps. The advantage of the latter over hashtables is a solid bound on the worst case running times.

Python is interesting experiment. In our computer programming classes we allow student to pick two language to major in. One must be choice of proper establish language like C , C++ , Perl, etc and other must be modern experimental choice like Python , Java , etc. Python has become most popular choice for second language at University, and I'm not sure why!

One good thing is that there now unicode file support for windows which was a big annoyance to the student before. Now they can actual code in Chinese and save files in Chinese names...

Another good point for international user is.. universal new line support which mean Python can now support Chinese newlines as well as American ones. Bravo Python team. A much more international liked language is coming along!

Python is interesting experiment. In our computer programming classes we allow student to pick two language to major in. One must be choice of proper establish language like C , C++ , Perl, etc and other must be modern experimental choice like Python , Java , etc. Python has become most popular choice for second language at University, and I'm not sure why!

One good thing is that there now unicode file support for windows which was a big annoyance to the student before. Now they can actual code in Chinese and save files in Chinese names...

Another good point for international user is.. universal new line support which mean Python can now support Chinese newlines as well as American ones. Bravo Python team. A much more international liked language is coming along!

Here, let me rewrite that for you:

Business Logic Java - Good
PHP - Bad.

Presentation Layer (Web)
Java/JSP - OK
PHP - OK

There, that's more in keeping with what I know of both languages. Now, Java is superior to PHP for business logic, as you picked out, but Java has JSP/Tomcat, which is functionally just as good as PHP, at least according to benchmarks I saw recently.

Now.. given the choice of Java over PHP for your presentation, why would anyone choose PHP when they can get the same results with JSP, but have the added upshot of keeping everything together in the same basic syntactic setup? Java code is easier to create and maintain than PHP code, and it's faster.

There's no real need to use a different system unless you get a benefit from it. You claim the benefit is in using PHP for presentation in web applications. Fine, but I don't see it. Now, if you suggested something along the lines of Zope's Page Templates, I might agree. But if you're at the point of using Zope for your presentation, there's no reason to use a different platform for the logic, as Zope is written in Python, and Python is an outstanding programming language, easily heads and shoulders above Java in every respect except raw number-crunching performance and IDE availabilty. At least, IMO. :)

But the question is Java vs. PHP. In that case, the answer is Java.

after all, haven't you seen the new Perl 7 spec?

For those of you who use python, you might want to check out the Python Imaging Library, or PIL for short.

After using many, many different tools for this type of thing (including IM, netPBM, GD, and my own tools), PIL has by far become my favorite for image processing.

Check out this simple tutorial for some examples of what you can do.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^HPerl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

4.15. Is it possible to write obfuscated one-liners in Python?

And, yes it is.

Though I do believe it is much easier to write readable, maintainable Python code than it is Perl code. I certainly find that I can understand my Python six months later. Perl is typically a different story.

I never was able to pin down exactly what it was about the style that I disliked.

Out of curiosity, I just checked out the BitTorrent code, and I can offer some concrete examples of what I don't like about it:

1. Almost no comments. Python has very good built in documentation features, and they are completely unused here.
2. Frequent use of single-letter variable names, or names that are abbreviated so heavily that someone unfamiliar with the code has no idea what they mean.
3. Very long lines. I saw a few that were about 160 characters long, twice what they should be.
4. Deeply nested code blocks. I'll have to agree with Linus Torvalds here, who said that if you're nesting more than three layers deep, you probably need to rethink what you're doing. Though I'd increase this to four layers for OOP languages like python.

I'm sure others can think of more. I don't mean to give this guy a hard time, though; I've definitely seen much worse, and some areas of the code actually seem fairly clean to me. Also, for anyone interested, there, is a good, standard for python coding style in PEP 8

Python already has a sort of system in place for block delimiters. Mind you, it's rather ugly, so I don't use it.

If there is a geek that I hate, it's a lying geek. Guido can at-least date a girl that is old enough to understand that she's dating a geek. I mean, c'mon. Guido's girlfriend is young enough to be his granddaughter! Guido, in my perspective, is committing child molestation if he thinks he can make such a young girl as his girlfriend!

:-)

I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):

posting 1

and Guido's reply:

posting 2

A little bit further down that thread we find this:

posting 3

Since this last one is particularly telling, I will quote the relevant text for our impatient readers:

I think Guido's rationale for removing all these features will be widely misunderstood. Me channeling him: it is not that he believes that the architectures developed were inherently incapable of providing security. Instead, he feels that no "expert" for these matters has reviewed these architecture for flaws, and that the continuing maintenance of these things isn't going to happen.

If this understanding is correct, then any new approaches will likely suffer from the same fate. Unless somebody steps forward and says: "I am a security expert, and I guarantee that this and that feature is secure (in some documented sense)", then I think he will dislike any changes that mean to provide security.

So this not a matter of engineering but of authority. Somebody must take the blame, and Guido doesn't want to be that someone.

Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.

I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):

posting 1

and Guido's reply:

posting 2

A little bit further down that thread we find this:

posting 3

Since this last one is particularly telling, I will quote the relevant text for our impatient readers:

I think Guido's rationale for removing all these features will be widely misunderstood. Me channeling him: it is not that he believes that the architectures developed were inherently incapable of providing security. Instead, he feels that no "expert" for these matters has reviewed these architecture for flaws, and that the continuing maintenance of these things isn't going to happen.

If this understanding is correct, then any new approaches will likely suffer from the same fate. Unless somebody steps forward and says: "I am a security expert, and I guarantee that this and that feature is secure (in some documented sense)", then I think he will dislike any changes that mean to provide security.

So this not a matter of engineering but of authority. Somebody must take the blame, and Guido doesn't want to be that someone.

Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.

I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):

posting 1

and Guido's reply:

posting 2

A little bit further down that thread we find this:

posting 3

Since this last one is particularly telling, I will quote the relevant text for our impatient readers:

I think Guido's rationale for removing all these features will be widely misunderstood. Me channeling him: it is not that he believes that the architectures developed were inherently incapable of providing security. Instead, he feels that no "expert" for these matters has reviewed these architecture for flaws, and that the continuing maintenance of these things isn't going to happen.

If this understanding is correct, then any new approaches will likely suffer from the same fate. Unless somebody steps forward and says: "I am a security expert, and I guarantee that this and that feature is secure (in some documented sense)", then I think he will dislike any changes that mean to provide security.

So this not a matter of engineering but of authority. Somebody must take the blame, and Guido doesn't want to be that someone.

Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.

Looking at Guido's Home Page I noticed that his picture shows a clean, healthy looking guy with all his hair.
I hereby cast my vote for Guido VanRossum for Least Ugly Open-Source Project Leader.

Guido seems to disagree.

GvR: In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

Now you might be splitting hairs and saying that "static" means known at compile time and "strong" means type errors are always detected, but in common parlance "strong typing" includes static typing. For the pedants, there's Sebesta:

...we define a programming language to be strongly typed if type errors are always detected. This requires that the types of all operands can be determined, either at compile time or at run time.

This criterion is met by very few real-world languages. Most imperative and object-oriented languages include type coercion which contradicts this property. It is interesting to note that future Python development is moving towards still stronger typing -- and, dare I say it -- functional-style constructs.

Of course, the pragmatic thing to do is to understand strong/weak typing not as binary, but as a continuum. In this case, Haskell is more strongly typed than Ada is more strongly typed than Python is more strongly typed than C++ is more strongly typed than C is more strongly typed than FORTRAN. It looks like Python 3.0 will be moving up the chain, however.

Python is actually simpler than Perl -- it's designed to be so. HOWEVER, Perl is also designed to do many specific things very simply, so when you need to do one of those specific things it's the fastest way to get it done -- assuming, of course, that you already knew Perl could do it :-).

I'm a Python fan, but I doubt Python will ever surpass Perl -- especially not by adding a "more logical parse tree", since it already has a very simple, consistent, and logical parse tree whereas Perl has more of a parse forest. Python and Perl are just too different; they compete in many areas, but their real strengths are far enough apart to keep them both viable in each other's presence.

For info on what projects are being done in Python, see the lists at www.python.org (Success Stories, Python Users, and Python Projects)).

Remarkable language, Python. Lovely plumage!

-Billy

Python is actually simpler than Perl -- it's designed to be so. HOWEVER, Perl is also designed to do many specific things very simply, so when you need to do one of those specific things it's the fastest way to get it done -- assuming, of course, that you already knew Perl could do it :-).

I'm a Python fan, but I doubt Python will ever surpass Perl -- especially not by adding a "more logical parse tree", since it already has a very simple, consistent, and logical parse tree whereas Perl has more of a parse forest. Python and Perl are just too different; they compete in many areas, but their real strengths are far enough apart to keep them both viable in each other's presence.

For info on what projects are being done in Python, see the lists at www.python.org (Success Stories, Python Users, and Python Projects)).

Remarkable language, Python. Lovely plumage!

-Billy

The obvious reference to Python Web Site will give more information. Python often competes in the same space as perl. But, Python is probably more object oriented than perl. The difference being that python is OO from the ground up as opposed to perl where it was added late. Most of Redhat's installation tools and scripts are written in python. A 3d game a few years ago 'Blade of Darkness' was done with mostly python.

It is being worked on -- PyPI (Python Package Index). It's quite new, so it's not as big as CPAN, and doesn't do a lot of things CPAN does (many of which I'm sure I'm unaware of) since it's just an index. But it is specifically intended to be a start on the path to CPAN. The distutils package for Python is another piece of the puzzle, to make distribution and installation easier.

From Python.org Python is named after the BBC show 'Monty Python's Flying Circus' and has nothing to do with nasty reptiles. Making references to Monty Python skits in documentation is not only allowed, it is encouraged! Also, many of google's engineers use Python, and I hear they are constantly looking for more people with skills in this language. From Python.org

From Python.org Python is named after the BBC show 'Monty Python's Flying Circus' and has nothing to do with nasty reptiles. Making references to Monty Python skits in documentation is not only allowed, it is encouraged! Also, many of google's engineers use Python, and I hear they are constantly looking for more people with skills in this language. From Python.org

...also due to Python being completely GPLd!

While I generally agree with your post, you gave this incorrect information several times. Python is not licensed under the GPL. It uses its own unique license that is more similar to the LGPL or BSD than the GPL.

I know of at least three free debuggers. One is PDB. Another is PythonWin. And finally there is IDLE.

I know of at least three free debuggers. One is PDB. Another is PythonWin. And finally there is IDLE.

I was going on this link, that I should have read more carefully before posting that date. Coding started late '89, it was used internally during '90, the first release was in early '91.

But of course, there's nothing that comes close to CPAN anywhere else. It's also beautiful to see a CPAN install, automatically grabbing lots of modules and installing everything correctly :-). There are only a few Linux distributions that can do the same sort of thing, I think.

You're right about 1987 for Perl's origin, but the earliest origin for Python seems to be 1991, and it doesn't look like it actually went anywhere until 1995. In any case, age is really a proxy for the amount of development that's occurred on a language, and it still seems that Perl is way ahead on modules.

Maybe not quite as many modules as Perl, but the standard Python library provides interfaces for a lot of different tasks. It's not skimpy, in case any of you potential Python users was worried.

There's good reason the motto is "Batteries Included".

I've found Python useful for all kinds of tasks and love the clean, short syntax devoid of punctuation characters.

If you need more of a recognized authority to recommend how great and wonderful is Python, then listen to Bruce Eckel or Eric Raymond.