Could Python supplant Java?

Pekka Niiranen krissepu at vip.fi
Tue Aug 20 13:12:21 EDT 2002


IMHO,

        both languages have the same problem: they are too slow.

        As long as Python cannot be compiled, we need map(), filter() 
and reduce().
        The idea of "one obvious way to do it"  is plain stupid with 
current performance.
        As those efforts to interface to C -code show too: more power is 
needed.

        As soon as Scheme gets better unicode support, I will switch.

-pekka-

brueckd at tbye.com wrote:

>On 20 Aug 2002, FISH wrote:
>
>>>IMHO, compile time type-checking is a nice safety net, but if you get a 
>>>type error at compilation, it still means you made a mistake. 
>>>
>>Yes, but the error is flagged in compilation, as opposed to
>>five weeks after the product ships, when it crops up in a bug
>>report from a customer.
>>
>
>Have you done any analysis or classification of your bugs that actually 
>shows that the bugs found in production would equate to syntax errors in a 
>compiled languaged? Anecdotally they tend to be two different types of 
>bugs; also I just scanned through our entire internal Bugzilla list and 
>see two things:
>
>1) The production bugs in C++ and Java are similar to the ones in Python.
>2) None of the Python bugs would have been found at compile time in a 
>statically-typed language.
>
>>Strong and weak typing have their place.  Dynamic types are less
>>hassle to work with, but of course they push an added burden of
>>testing onto the developer
>>
>
>You are deceiving yourself if you think (at least a good portion of) the
>burden of testing is not already on the developer. The difference between
>static and dynamic typed languages is that with the dynamicly-typed
>language you don't have the false sense of security. You should be
>suspicious of all warm fuzzies derived from code that successfully
>compiles. :-)
>
>>This is one of the reasons why I do not consider Python a suitable
>>alternative to Java.  Dynamic typing is fine for scripts, but when 
>>it comes to full-blown 'ten thousand line' applications you really
>>should be looking as something IMHO which gives you the added
>>security of strong typing, to catch as many potential bugs as
>>possible.
>>
>
>I think you mean 'static' and not 'strong' typing as Python *is* stronly 
>typed.
>
>The perception that dynamically-typed languages don't work for large 
>applications is common, but it is a common *mis*conception (for example, 
>Google for one of the recent threads about successful large Python 
>applications - despite Python's limited popularity there are actually 
>quite a few large and successful Python projects - certainly too many to 
>be a fluke!).
>
>One reason why your fear doesn't turn out to be true is the reason I 
>mentioned above: the bugs found in the field aren't the kind caught by 
>a compiler. They are algorithmic or coverage bugs - much higher level than 
>syntactic errors. They are bugs that stem from false assumptions or 
>unanticipated scenarios - the same screwups you make whether your language 
>is Python or C++. The difference is that in, say, C++ you have these kinds 
>of bugs PLUS the bugs that are due to incorrect memory management, use of 
>lower-level data structures, rigidly defined data types, etc. You end up 
>having MORE bugs because the developer has to manage far more details.
>
>I'll go so far as to say that languages such as C++, VB, Java, are
>actually *less* suitable for very large projects than Python, and their
>suitability *decreases* as the size of the project increases. Languages
>like Python actually enable the clean and robust creation of larger
>programs by smaller groups of people - its clean syntax, high-level 
>built-in data types, automatic memory management, low cost of change, etc. 
>all combine to push back the limits of program complexity - the point at 
>which the application becomes too large and complex to manage. 
>
>Whatever comes after Python will further extend the limit of what a
>program can be before becoming too complex. Moving from assembly language
>to C opened the door to larger and more complex applications for the same
>reasons, and moving from C++ or Java to Python yields similar results.
>
>>>in C, you can have type error when casting a void*, and you don't have 
>>>any info about the original type of the pointeur. Dynamic typing doesn't 
>>>means Python is not *strongly* typed.
>>>
>>Surely the two are mutually exclusive?  Unless this is some very
>>novel use of the word 'strongly'?  :-)
>>
>
>No. From section 3.1 of the Language Reference:
>
>"Every object has an identity, a type and a value. An object's identity 
>never changes once it has been created ... An object's type is also 
>unchangeable."
>
>Don't confuse objects with references to objects.
>
>-Dave
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20020820/79273799/attachment.html>


More information about the Python-list mailing list