Could Python supplant Java?

[laotseu]

FISH wrote:
> laotseu <bdesth at nospam.free.fr> wrote in message news:<3D631FF3.7060804 at nospam.free.fr>...
> 
>>FISH wrote:
>>
>>>laotseu <bdesth at nospam.free.fr> wrote in message news:<3D61A538.2050107 at nospam.free.fr>...
>>>[snip...]
>>>
>>>
>>>>I used to think the same (what about VB's 'variant' ? yuk !)... But 
>>>>python's dynamic typing has got me, specially in the case of oo 
>>>>programming. It makes polymorphism a really simple thing.
>>>
>>>
>>>And more dangerous :-)
>>>
>>
>>What is the more dangerous : relying on the compiler or knowing what you 
>>do when wrting code ? It's more about the way you work than about the 
>>language you use.
> 
> 
> 
> Aha - you must be one of those rare creatures who writes 
> thousands of lines of code which is all 100% bug free.  The
> rest of us mere mortals unfortunately are not so lucky.  :-)
> 

I wish this were true :-(

I just wanted to say that :
- it's the programmer responsability to pass good args to a function
- it's also the programmer responsability to write test cases.


> Most of the developements in software engineering over the 
> decades have focused around giving programmers the tools to
> write software with less chance of bugs - meaning we can
> push the science harder and longer while not vanishing up
> our own backsides under the weight of all the errors we
> create.  Let's face it - if it wasn't for the need to 
> reduce errors and write more dependable code, nobody would
> have invented third generation languages, or structured
> programming practices, or object orientation for that
> matter.  All of these 'devices' are meaningless at the 
> machine code level - they exist merely to serve programmers
> with ways to construct stronger, more reliable, software.
> 

As someone else said elsewhere in this thread, the higher level the 
langage, the more you can write complex programs. In this cas, and IMHO, 
  dynamic typing means higher level.


> 
>>>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.
>>
>>
>>Programs *should* be tested before shipping
>>(ok, I know it's a dream but... )
> 
> 
> Software testing is the *LAST* line of defense against bugs,
> not the *FIRST* !!!  ;-)
> 
> A good programmer uses appropriate techniques and tools to
> try to minimise the number of bugs which get into software
> in the first place - before it even hits testing.
> 

I do not agree. Unit testing *is* the first line of defense. You should 
write tests first, and only then write code.

> [snip...]
> 
>>> Dynamic types are less
>>>hassle to work with, but of course they push an added burden of
>>>testing onto the developer
>>
>>No. Write (good) tests first, then write your code, then let the 
>>computer run the tests.
> 
> 
> 
> And how do I test the tests?  (If your test software is there to
> ensure your program works - what is ensuring your test software
> works?  Do you have test test software?  And test test test 
> software?)  We're back to what I said before - testing is the
> LAST line of defense against bugs.
> 

Oh, come on. Unit tests are not so difficult to write. I dont mean 
having a 'test software', I'm talking about *unit* testing.

You certainly won't catch *all* bugs with unit tests, but you'll sure 
catch more bugs, and more *important* ones, with this than relying on a 
compiler to check types.

BTW, if you absolutly needs args type checking, it's not a difficult 
thing to do in Python, and this can be part of the unit tests.


> 
>>>- because mistakes are not so easily
>>>spotted.  
>>
>>Your compiler won't spot most of the mistakes. Well written tests will.
> 
> 
> How do you know the tests are well written? 

Because *I* wrote them !-)))
(sorry, I could not resist)

> You're relying on the
> validity of one piece of software you wrote to check the validity 
> of another piece of software you wrote.  (And at the same time you
> seem to poo-poo the idea of allowing the compiler - which is just
> a piece of software after all - to check the vailidity of your code!)

*You* rely on a piece of software *you* didn't wrote to check your code. 
And *that* piece of software cannot check for much more than typing 
errors. That's the difference.


> Were as I have nothing against writing test software (all in favour, 
> in fact) it compliments other tools - such as using static datatypes 
> to ensure the compiler can check your handling of the data they carry.
>

See above... You can *very easily* add a type checking mechanism in your 
code and tests, if you feel this is *necessary* for some particular 
piece of code. The extra work is nothing compared to the extra work a 
statically typed langage forces you to do (at least in poo).

> Okay - not all software grows to the size where an average human
> cannot keep track of data usage in variables.  So for languages
> which specialise in small single purpose code (often falling under
> the category of 'scripts' - although this is very much a general-
> isation) it is possible to discard fixed data types for variables
> for a more flexible system.
> 
> 
> 
>>>However, for languages targetted maining at scripting 
>>>(scripts tend to be brief by their very nature) then the added
>>>burden of dynamic typing is managable, and the benefits often
>>>outweigh the problems.
>>>
>>>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.
>>>
>>
>>Ok. Objective C has dynamic typing. Whole Operating systems have been 
>>written in Objective C. Would you  consider that :
>>- Objective C is not suited for anything else than scripting ?
> 
> 
> Yes.

Ok, this is pure 'mauvaise foi' (pardon my french).

>  It may have many virtues, but I would not be my first choice
> for large scale or complex projects. 

We were not talking about *your* first choice, but about the fact that a 
langage with dynamic typing could be used for complex, large scale 
projects.

> That's not to say you *cannot*
> write large scale or complex project in it - just that other 
> languages (like C/++ and Java) would be better.

That's an opinion, not fact.

> 
>>- Java would be a sensible choice for writing an OS ?
> 
> 
> No.  Although this is one of the few large scale projects I would
> not consider Java suitable for.  Ultimately Java is designed to
> run atop a VM, so extreme low level and/or time critical code
> is best tackled in another language.  The choice of 'OS' was a
> poor one for the example's sake.
>  

I agree with that point.

> 
>>(NB : I'm *not* suggesting Python would be a good choice if you plan to 
>>write an OS)
> 
> 
> Again - you *could* write an OS in Python I'm sure - but other
> languages would be better (and more bug resistant!) when handling
> that volume of code.
> 

It's not a matter of 'bug resistance' (whatever 'bug resistance' may be, 
I don't know of any langage being more or less 'bug resistant'). The 
higher level the langage, the easier you can manage large and complex 
code (IMHO).

Also, the C langage is not very 'bug resistant' (if I understand your 
meaning of the 'bug resistance' concept), and makes any kind of code 
much more complex than Python. This is still the most used langage for 
system programming.

Laotseu



Laotseu