The Industry choice

C

Cameron Laird

As I wrote on my weblog a while ago, I suspect that this effect is
largely psychological. You jump through hoops, declaring types all over
the place, checking exceptions, working around the language's
limitations, etc. So when your code compiles, it *feels* safer. Like
you're at least part of the way towards ensuring correctness. All that
work must be good for *something*, right? Never mind that when writing
unit tests for a dynamic language, you don't check for these things at
all. How often do you explicitly check types in Python unit tests?
IMHO, when using a dynamic language, you don't need most of the checks
that Java, C# and their ilk force upon you.
.
.
.
Me, too.

That is, while I have a LOT of respect for Paul's programming
and judgment, and question myself when I'm on the side opposite
him, I ultimately value type declarations in languages such as
Java as more cost than benefit.

It's a funny position to hold, because I simultaneously recognize
that type theory is one of computing's strongest theoretical
achievements, AND I am a strong advocate of "static" syntax checkers
such as PyChecker. Still, I see TDD as the right place to start.
 
C

Cameron Laird

Large-scale scientific computing projects, such as numerical weather
prediction, where performance is critical. Python could be used as the
"glue" but not the "guts", where Fortran 95 and C++ are more
appropriate. In my tests, some posted here, there has been a
.
.
.
I feel like growling that it's clearly a mistake for large-scale
scientific computing projects not to leverage dynamic languages,
at least in part. Yes, I've seen projects that would have been
disasters if done entirely in Python. I've also seen many, many
large-scale scientific projects that soaked up far more resources
than they should have because they limited themselves to C++ or
Fortran.

I argue that it's a false opposition to categorize projects in
terms of use of single languages. Many projects are MUCH better
off with a mix of Python and Fortran, say (and probably SQL and
JavaScript and ...), and it's pernicious to accomodate the
managerial conceit that One Language will suffice.
 
S

Steve Holden

Paul Rubin wrote:

[...]
There's lots of times when I have a cool programming idea, and find
when I sit down at the computer that I can implement the main points
of the idea and get a neat demo running rather quickly. That creates
a very happy, liberating feeling, plus gives me something to show off
to friends or co-workers. But turning it into a finished product with
no rough edges is an order of magnitude more work. It seems to me
that IDLE and a lot of the rest of Python are examples of someone
having a cool idea and writing a demo, then releasing it with a lot of
missing components and rough edges, without realizing that it can't
reasonably be called complete without a lot more work.

^Python^open source^

regards
Steve
 
S

Steve Holden

Paul Rubin wrote:

[...]
There's lots of times when I have a cool programming idea, and find
when I sit down at the computer that I can implement the main points
of the idea and get a neat demo running rather quickly. That creates
a very happy, liberating feeling, plus gives me something to show off
to friends or co-workers. But turning it into a finished product with
no rough edges is an order of magnitude more work. It seems to me
that IDLE and a lot of the rest of Python are examples of someone
having a cool idea and writing a demo, then releasing it with a lot of
missing components and rough edges, without realizing that it can't
reasonably be called complete without a lot more work.

^Python^open source^

regards
Steve
 
S

Steve Holden

Cameron said:
.
.
.
I feel like growling that it's clearly a mistake for large-scale
scientific computing projects not to leverage dynamic languages,
at least in part. Yes, I've seen projects that would have been
disasters if done entirely in Python. I've also seen many, many
large-scale scientific projects that soaked up far more resources
than they should have because they limited themselves to C++ or
Fortran.

I argue that it's a false opposition to categorize projects in
terms of use of single languages. Many projects are MUCH better
off with a mix of Python and Fortran, say (and probably SQL and
JavaScript and ...), and it's pernicious to accomodate the
managerial conceit that One Language will suffice.

Indeed it's sensible to choose language based on the nature of the task
to be performed, to avoid "language-blindness" and to build systems in
mixed languages.

Unfortunately the hierarchy of power in most modern commercial and
academic organizations is such that large-scale efforts will be
nominally run by single individuals, and since those individuals
typically can dispense favors and determine who advances within the
organization it's often unwise *not* to accommodate the managerial
conceit it career advancement is one's primary goal.

which-is-why-i-run-my-own-business-ly y'rs - steve
 
D

Donn Cave

Quoth Hans Nowak <[email protected]>:
| Paul Rubin wrote:
|
|> You should write unit tests either way, but in Python you're relying
|> on the tests to find stuff that the compiler finds for you with Java.
|
| As I wrote on my weblog a while ago, I suspect that this effect is
| largely psychological. You jump through hoops, declaring types all over
| the place, checking exceptions, working around the language's
| limitations, etc. So when your code compiles, it *feels* safer. Like
| you're at least part of the way towards ensuring correctness. All that
| work must be good for *something*, right? Never mind that when writing
| unit tests for a dynamic language, you don't check for these things at
| all. How often do you explicitly check types in Python unit tests?
| IMHO, when using a dynamic language, you don't need most of the checks
| that Java, C# and their ilk force upon you.

I have been fooling around with strongly, statically typed languages
for a couple of years, in my spare time - Objective CAML, Haskell,
O'Haskell. This is a little different experience than what you two
are talking about - I don't think Java, C# and their ilk are quite as
rigorous, nor do they use type inference - but as much as it would
probably gag an FP enthusiast to say this, the basic idea is the same.

I can only believe that if you think the benefit of static typing is
psychological, either something is very different between the way you
and I write programs, or you're not doing it right.

For me, the effect is striking. I pound out a little program, couple
hundred lines maybe, and think "hm, guess that's it" and save it to
disk. Run the compiler, it says "no, that's not it - look at line 49,
where this expression has type string but context requires list string."
OK, fix that, iterate. Most of this goes about as fast as I can edit,
sometimes longer, but it's always about structural flaws in my program,
that got there usually because I changed my mind about something in
midstream, or maybe I just mistyped something or forgot what I was doing.
Then, when the compiler is happy -- the program works. Not always, but
so much more often than when I write them in Python.

Now you may repeat here that we all must make thorough unit testing
a cornerstone of our Python programming, but don't tell me that the
advantage of static typing is psychological. It does substantially
improve the odds that a program will be correct when it runs, because
I have seen it happen.

If unit testing does so as well, then obviously there will be some
redundancy there, but of course only where you actually have complete
coverage from unit testing, which not everyone can claim and I'm sure
even fewer really have. And like the man said, you're doing that work
to find a lot of things that the compiler could have found for you.

Donn Cave, (e-mail address removed)
 
H

Hans Nowak

Donn said:
Quoth Hans Nowak <[email protected]>:
| Paul Rubin wrote:
|
|> You should write unit tests either way, but in Python you're relying
|> on the tests to find stuff that the compiler finds for you with Java.
|
| As I wrote on my weblog a while ago, I suspect that this effect is
| largely psychological. You jump through hoops, declaring types all over
| the place, checking exceptions, working around the language's
| limitations, etc. So when your code compiles, it *feels* safer. Like
| you're at least part of the way towards ensuring correctness. All that
| work must be good for *something*, right? Never mind that when writing
| unit tests for a dynamic language, you don't check for these things at
| all. How often do you explicitly check types in Python unit tests?
| IMHO, when using a dynamic language, you don't need most of the checks
| that Java, C# and their ilk force upon you.

I have been fooling around with strongly, statically typed languages
for a couple of years, in my spare time - Objective CAML, Haskell,
O'Haskell. This is a little different experience than what you two
are talking about - I don't think Java, C# and their ilk are quite as
rigorous, nor do they use type inference - but as much as it would
probably gag an FP enthusiast to say this, the basic idea is the same.

I can only believe that if you think the benefit of static typing is
psychological, either something is very different between the way you
and I write programs, or you're not doing it right.

I do think it makes more sense in functional languages like the ones you
mention... that's one of the reasons I am trying to learn OCaml. I
don't think the type systems in OCaml, Haskell etc can quite be compared
to what's used in Java, C#, C++ or Delphi. So far, I am getting the
impression that the type system in OCaml is actually there to help you,
rather than something that gets in your way.

I concur that in my OCaml experiments so far, errors pointed out by the
compiler made a lot more sense, because they pointed to actual problems,
rather than being a case of "you didn't declare this method as public
static final".

Of course, it helps that, like Python, said languages (OCaml, Haskell)
are higher-level than Java/C#/etc, so you can express things concisely
and clearly. That might be one of the reasons why static, strong typing
in VHLLs has a much higher "return on investment" than it has in
lower-level languages, where you have to write acres of code just to get
something done (availability of libraries notwithstanding).
 
R

Rob Emmons

For managers of companies it's worse: the company makes
VERY substantial investments into any technology it "marries",
and that means big losses if it goes. Long-term stability
of this technology in terms of "we're not going to be left out
in cold alone with this technology to feed it" means a lot
to them. Even a poor technology with external backing
of big, stable vendor is better than the excellent technology
without ......

There is the stability issue you mention... but also probably the fear
issue. If you choose a solution from a major company -- then it fails for
some reason or they drop the product -- it's their fault -- you've got an
automatic fall guy. On the other hand, an open source solution or
otherwise less accepted solution ... it will probably be consider
your fault by the organization. It's a rational decision to avoid
personal risk when you don't get much reward for choosing something
different.

Rob
 
S

Steve Holden

Rob said:
There is the stability issue you mention... but also probably the fear
issue. If you choose a solution from a major company -- then it fails for
some reason or they drop the product -- it's their fault -- you've got an
automatic fall guy. On the other hand, an open source solution or
otherwise less accepted solution ... it will probably be consider
your fault by the organization. It's a rational decision to avoid
personal risk when you don't get much reward for choosing something
different.
You are ignoring the fact that with the open source solution you do at
least have the option of hiring bright programmers to support the
framework which has now become moribund, whereas when a company goes
bust there's no guarantee the software IP will ever be extricated from
the resulting mess.

So I'm not sure I'd agree with "rational" there, though "comprehensible"
might be harder to argue with.

Personally I'd feel in a better position standing before a Board of
Directors and saying "While it's true that our chosen software platform
isn't being supported by the original team any more, we do have options
to continue to move it forward, including forming a consortium with
other users".

Avoidance of blame is way too large a motivator in large organizations,
and it leads to many forms of sub-optimal decision making.

regards
Steve
 
P

Paul Rubin

Steve Holden said:
^Python^open source^

I wouldn't say so. I'd say the Linux kernel, GCC, Emacs, Apache,
Mozilla, etc. are all developed with a much more serious attitude than
Python is. Of course there are lots of other FOSS programs that
someone wrote for their own use and released, that are less polished
than Python, but that are also the subject of less advocacy than Python.
 
P

Paul Rubin

That is, while I have a LOT of respect for Paul's programming
and judgment, and question myself when I'm on the side opposite
him, I ultimately value type declarations in languages such as
Java as more cost than benefit.

I don't find static type declarations to have much cost. It's just a
few more keystrokes. I'm open to persuasion about whether they have
benefit.

I do believe that it's a horrible deficiency in Python that it has no
declarations at all, even optional ones, like "perl -w" or "use
strict". Python's scoping hacks that result from the lack of
declarations just seem to me like pure insanity.

I was pretty skeptical of Java's checked exceptions when I first used
them but have been coming around about them. There's just been too
many times when I wrote something in Python that crashed because some
lower-level function raised an exception that the upper level hadn't
been expecting, after the program had been in use for a while. I'd
sure rather find out about that at compile time.
 
B

beliavsky

Paul said:
I don't find static type declarations to have much cost. It's just a
few more keystrokes. I'm open to persuasion about whether they have
benefit.

Overall I agree with you and would like to have OPTIONAL static type
declarations in Python, as has often been discussed. But without
facilities for generic programming, such as templates in C++, static
type declarations can force one to duplicate a LOT of code, with one
sorting routine each for integer, floats, strings, etc. Some algorithms
are type invariant, and Python is a concise language for expressing
those algorithms.
 
A

Alan Gauld

I argue that it's a false opposition to categorize projects in
terms of use of single languages. Many projects are MUCH better
off with a mix

In practice I have *never* worked on an industrial scale project
that only used one language. The nearest I came was a small
protocol convertor that only used C, SQL and some shell and
awk - but that's still 4 languages! And the whole project was
only 40,000 lines of code in about 20 files.

And most projects use many more, I'd guess around 5-8 on an
"average project" of around 300-500kloc. The biggest project I
worked on had about 3.5Mloc and used:

Assembler (680x0 and Sparc),
C
C++
Lisp(Flavors)
awk
Bourne shell
C shell - this was a mistake discovered too late to "fix"
PL/SQL
???? - A UI description language for a tool called TeleUse...
Pascal - No, I don't know why...
ASN.1 - with a commercial compiler

We also had some IDL but since it was tool generated I'll ignore
it...

We also had an experimental version running on a NeXt box so it
used Objective C for the UI instead of ???? and C++...

A total of 13 languages... with 5 geographically dispersed teams
comprising a total of 200 developers (plus about 40 testers).
Interesting times...in the Chinese sense!

Alan G
Author of the Learn to Program website
http://www.freenetpages.co.uk/hp/alan.gauld
 
A

Aahz

I was pretty skeptical of Java's checked exceptions when I first used
them but have been coming around about them. There's just been too
many times when I wrote something in Python that crashed because some
lower-level function raised an exception that the upper level hadn't
been expecting, after the program had been in use for a while. I'd
sure rather find out about that at compile time.

That's funny -- Bruce Eckel talks about how he used to love checked
exceptions but has come to regard them as the horror that they are.
I've learned to just write "throws Exception" at the declaration of
every method.
 
P

Paul Rubin

Overall I agree with you and would like to have OPTIONAL static type
declarations in Python, as has often been discussed. But without
facilities for generic programming, such as templates in C++, static
type declarations can force one to duplicate a LOT of code, with one
sorting routine each for integer, floats, strings, etc.

I don't see that big a problem. The current Python sorting routine
operates on instances of class "object" and calls the __cmp__ method
to do comparisons. Every class of sortable objects either defines a
__cmp__ method or inherits one from some superclass, and sort calls
those methods. Static type declarations would not require writing any
additional sorting routines.
 
N

Nick Coghlan

Paul said:
I don't see that big a problem. The current Python sorting routine
operates on instances of class "object" and calls the __cmp__ method
to do comparisons. Every class of sortable objects either defines a
__cmp__ method or inherits one from some superclass, and sort calls
those methods. Static type declarations would not require writing any
additional sorting routines.

Python's list.sort doesn't check the *type* of the arguments at all. It only
looks for the relevant comparison methods (__cmp__ or __lt__, as I recall).

Sure, classes written in *Python* will ultimately inherit from either object or
types.ClassType, but extension classes need not do any such thing.

Yet list.sort works with them all, anyway.

Cheers,
Nick.
 
D

Donn Cave

Quoth Paul Rubin <http://[email protected]>:
| (e-mail address removed) writes:
|> Overall I agree with you and would like to have OPTIONAL static type
|> declarations in Python, as has often been discussed. But without
|> facilities for generic programming, such as templates in C++, static
|> type declarations can force one to duplicate a LOT of code, with one
|> sorting routine each for integer, floats, strings, etc.
|
| I don't see that big a problem. The current Python sorting routine
| operates on instances of class "object" and calls the __cmp__ method
| to do comparisons. Every class of sortable objects either defines a
| __cmp__ method or inherits one from some superclass, and sort calls
| those methods. Static type declarations would not require writing any
| additional sorting routines.

Yes, it would be really weird if Python went that way, and the
sort of idle speculations we were reading recently from Guido
sure sounded like he knows better. But it's not like there aren't
some interesting issues farther on downstream there, in the compare
function. cmp(), and str() and so forth, play a really big role in
Python's dynamically typed polymorphism. It seems to me they are
kind of at odds with static type analysis, especially if you want
type inference -- kind of a type laundering system, where you can't
tell what was supposed to be there by looking at the code. Some
alternatives would be needed, I suppose.

Donn Cave, (e-mail address removed)
 
P

Paul Rubin

Donn Cave said:
Yes, it would be really weird if Python went that way, and the
sort of idle speculations we were reading recently from Guido
sure sounded like he knows better. But it's not like there aren't
some interesting issues farther on downstream there, in the compare
function. cmp(), and str() and so forth, play a really big role in
Python's dynamically typed polymorphism. It seems to me they are
kind of at odds with static type analysis

I don't understand that. If I see "str x = str(3)", then I know that
x is a string.
 
E

Eric Pederson

Cameron said:
Let me add a cautionary note, though: Big Companies,
including Oracle, Software AG, IBM, Cisco, and so on, have
adopted Tcl over and over. All of them still rely on Tcl
for crucial products. All of them also have employees who
sincerely wonder, "Tcl? Isn't that dead?"

I offer this as a counter-example to the belief that Adop-
tion by a heavyweight necessarily results in widespread
acceptance.
--


I think the adoption of computer languages is quite complex, but one useful metaphorical model may be gravity, e.g. the clumpy universe of stars, with gravity working on different scales to shape the overall distribution of matter. Adoption by a heavyweight may have some effect if that force is allowed to operate on other bodies, but the overall distribution of "mass" is complex.

In the practice of business, companies generally find a need to consciously limit methodological diversity as they grow in size. Control is usually made more centralized, but becomes more distant from the atom (programmer writing code) as the firm grows large, and entropy becomes the enemy, lower level entropy a source of uncertainty and risk. If so, there is some legitimate reason for trying to "standardize" on tools (i.e. programming languages).

Less sophisticated business minds may latch onto the notion of gains from economies of scale, which is usually an easy sell (and good route for a fast career rise) but an overly simple optimization.

Not to say that such restrictive mindsets and policies are inevitable, but they seem the prevailing wind.

Preserving intellectual diversity and innovation may be critical to a big company in the long run, and allowing the use of (for example) Python would seem very in tune with those goals.

It might be nice if it was widely understood (in IT) that Python was a language any competent programmer could pick up in an afternoon, such that Java, C, and Perl shops would not be concerned about the need for their staff to learn a new language.



Eric Pederson
"Linear? What is linear?"




Digital M4 (music) http://www.songzilla.blogspot.com
:::::::::::::::::::::::::::::::::::
domainNot="@something.com"
domainIs=domainNot.replace("s","z")
ePrefix="".join([chr(ord(x)+1) for x in "do"])
mailMeAt=ePrefix+domainIs
:::::::::::::::::::::::::::::::::::
 
P

Peter Dembinski

[...]
I don't understand that. If I see "str x = str(3)", then I know
that x is a string.

def foo(x):
return str(x)

str = foo(x)

And now, let's say that foo()'s definition is in another module.
It is hard for a programmer to quickly determine the type for str,
that's the problem with programming in languages that don't have
type declarations.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top