Could Python supplant Java?

[James J. Besemer]

laotseu wrote:

> Certainly not me, and I do agree that having type check *as an option*,
> in a Lisp-like way, would benefit almost any language.

<Gasp>  Agreement!  ;o)

> Is 'number_of_lines' the only way to evaluate a project's complexity ?

Certainly not the only way but the simplest and better IMHO than some proposed
alternatives such as function points.

> I'm not sure. BTW, if used, there should be a weight factor - hi level
> languages (like Lisp or Python) usually needs much less lines to make
> the thing work than lo level ones

Alas, Disagreement!  ;o(

[I will admit that when comparing project sizes in different languages, lines of
code is not an exact comparison.  However, I argue at length in another post why I
think productivity gains that genuinely may be very high on small projects do not
carry over to large ones.]

If you disagree, Read Fred Brooks' "No Silver Bullet":

    http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html

He's smarter and wiser even than me.


> >>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.
> >
> > As a statement of opinion, nobody can argue.  But as a statement
> > of fact (as you've written it) I think it's more accurate to say the jury
> > is still out on this trade-off.  Certainly the substantially larger installed
> > bases in Each of the three alternatives is a partial counter-argument.
>
> Well... If you go this way, you should also state that Windows is a far
> better OS than Linux, xxxBSD or MacOs.

I didn't say installed base was the only factor.  Only that it might partly
contradict the earlier statement.  [Anyway, I think I made the case elsewhere that
it's a silly assertion.]

> I think you should read about the real reason why some languages are
> most used. [...] He's victim of an
> aggressive commercial politic. *We* (programmers) are also victims.

Oh yes, I am sure managers make mistakes like this all the time.

I watched one promising west coast business fail ultimately because upper
management could not come to grips with the benefits of rewriting all their product
code.  The code had cost millions and millions of dollars to develop but it all had
been written in assembly language for some crappy and obscure 8 bit CPU.  The
actual code could have been redone from scratch at a fraction of the original cost
in C or Pascal or just about anything on a newer CPU.  It was obvious to engineers
but management was clueless about software and could not see their way to do the
right thing until it was too late and by then it was... too late.  In a span of
about 5 years they went from #1 in the market and $35M in sales down to nothing.

Then too, in all fairness, I have on more than one occasion witnessed managers or
even entire businesses crash and burn, misled by egotistical techno geeks who
zealously pushed some latest and greatest technical miracle that was not ready for
prime time.  One example was an established east coast software business, again
with an aging code base.  Code I think was pretty much all in C and they had
growing difficulty maintaining the installed base and even greater difficulty in
adding new features to meet customers' evolving needs.  This time (after a merger)
the bold move of rewriting the entire code base was thrust upon engineering by
aggressive new executive management.  The initiative was championed by one geek who
sold the concept to the VP of engineering.  The reason it all was going to work and
furthermore be ready in just 1 year was that a new miracle cure was going to make
it all possible.  Instead of C they were going to rewrite everything in Smalltalk!
And "everybody knew" at the time that Smalltalk was 10X more powerful than C so
something like 1.5 million lines of code was going to be replaced by maybe 100K
lines of relly good Smalltalk.  This strategic technology would allow them to redo
their installed base and leapfrog the competiton at the same time.  So they
downsize the east coast office to just a maintenance staff and setup a 15 person
operation in the Bay Area to do the rewrite.  Of course, the "version 2" was late
by about a year and even then had profound performance problems (minutes to repaint
a screen).  It delivered on virtually all the technical specs but mised one single
sales requirement -- actually being something customers could use.  Over the course
of 3 or 4 years this $40M company also spiraled down to zip.  And this was during
the dot com boom.

But I digress....

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com