Language selection for new projects

[Limey Drink]

Hi

I have used recently for the odd shell scrit hear and there but nothing
really serious.
Software I have previously written has been in VB(urgh) and C++.

I have been thinking of changing my primary development landguage for some
time, this is partly because my software ideally needs to be cross platform
and partly because I feel there must be better cleaner/programmer friendly
languages out there so i have decided to bite the bullit and go for the
switch.

I was going to choose Java, but I like Python.

What are your thoughts on the viability of using Python on a fairly large
projects, I'm talking GUI, RDBMS access, COMMS.

Basically how does the language scale up in terms of portability,
performance, programmr friendliness(in terms of real sized programs not
small scripts) to Java.
My last concern is source code, is there any way to protect it from prying
eyes, obviously Java does have these issues but at least you can byte code
compile it.

Thanks in advance

[Alex Martelli]

Limey Drink wrote:
...

What are your thoughts on the viability of using Python on a fairly large
projects, I'm talking GUI, RDBMS access, COMMS.
Should be fine.
Basically how does the language scale up in terms of portability,
performance, programmr friendliness(in terms of real sized programs not
small scripts) to Java.
Quite well.
My last concern is source code, is there any way to protect it from prying
eyes, obviously Java does have these issues but at least you can byte code
compile it.

Python doesn't offer anything substantially different from Java here. You
can bytecode-compile things in advance, perhaps encrypt some modules
and decrypt them on the file on import, but it's really no protection --
just like in Java. Face it -- any time you give out executable source, be
it bytecode or machine-specific binary, it's easy to disassemble and crack
it -- game producers do their best to protect their wares, yet warez sites
always have cracks for everything of interest often before the product
they're cracking gets to store shelves -- what makes you think you can do
any better?

In the exceedingly unlikely case you have something really worth protecting,
don't give it out -- keep it as a webservice on a server under YOUR control,
and give out client programs that access this special protected software.
XML-RPC makes this trivial and comes with the standard Python distribution.

This strategy also allows you more flexibility in your business model
(subscription, pay-per-use -- you can enforce these with a web service
deployment, but not really if you distribute all the executable code). This
is reason #1 for the interest in recent years for web services, IMHO.
Alex

[Limey Drink]

Thankyou very much Alex, this is the first time I have attempted to use this
group for information and I am very pleased with the prompt response.

once again thanks

By the way, what do you think to Python with regards to productivity
benefits in general and also in comparison to other languages ?

Thanks

"Alex Martelli" <al*****@yahoo. com> wrote in message
news:lE******** **************@ news1.tin.it...

Limey Drink wrote:
...

What are your thoughts on the viability of using Python on a fairly large projects, I'm talking GUI, RDBMS access, COMMS.
Should be fine.

Basically how does the language scale up in terms of portability,
performance, programmr friendliness(in terms of real sized programs not
small scripts) to Java.

Quite well.

My last concern is source code, is there any way to protect it from prying eyes, obviously Java does have these issues but at least you can byte code compile it.

Python doesn't offer anything substantially different from Java here. You
can bytecode-compile things in advance, perhaps encrypt some modules
and decrypt them on the file on import, but it's really no protection --
just like in Java. Face it -- any time you give out executable source, be
it bytecode or machine-specific binary, it's easy to disassemble and crack
it -- game producers do their best to protect their wares, yet warez sites
always have cracks for everything of interest often before the product
they're cracking gets to store shelves -- what makes you think you can do
any better?

In the exceedingly unlikely case you have something really worth

protecting, don't give it out -- keep it as a webservice on a server under YOUR control, and give out client programs that access this special protected software.
XML-RPC makes this trivial and comes with the standard Python distribution.
This strategy also allows you more flexibility in your business model
(subscription, pay-per-use -- you can enforce these with a web service
deployment, but not really if you distribute all the executable code). This is reason #1 for the interest in recent years for web services, IMHO.
Alex

[Alex Martelli]

Limey Drink wrote:
...

Thankyou very much Alex, this is the first time I have attempted to use
this group for information and I am very pleased with the prompt response.

once again thanks
You're welcome.

By the way, what do you think to Python with regards to productivity
benefits in general and also in comparison to other languages ?

Python, in my experience, is the most productive language over its wide
range of optimal applicability. pyrex, a variant of Python which it might
be still a bit too early to consider fully mature enough for production
use, extends Python's applicability to somewhat "lower levels", in a sense.

I have seen people with particularly good mathematical mindsets do wonders
with functional programming languages, but I suspect those who'd be more
productive with those than with Python for typical applications would be a
tiny minority of the population. (This remains to be proven, but as a
working hypothesis it seems quite believable).

If you're after "tinkering" more than "production-level applications", don't
need to consider the issues of group cooperation, or are slowly weaning
yourself from the complexity of perl and don't want the shock of going "cold
turkey" into the simplicity of Python, Ruby may be a good compromise. Perl
itself is too complicated, and other scripting languages (Javascript and
variants, VBScript, bash & variants, PHP, IMHO Tcl too though some Tcl'ers
will disagree, awk, etc) too feeble, to compete for productivity with Ruby
or Python.

Other languages which, depending on cultural background, available
tools, and problem areas, may be competitive with Python include Lisp
(Common, maybe the lesser-known ISO kind, Arc if it ever matures, Scheme,
....), Dylan, Smalltalk -- and no doubt others that I haven't had a chance
to try out yet.

Looking at the kind of languages that currently appear to rule the roost --
C, C++, Java, C#, Visual (and other kinds of) Basic, Object Pascal,
Fortran, Objective C, Ada, Cobol, Eiffel -- it does not seem to me that any
of them can compete in terms of programmer productivity with the ones
listed above (I do not have sufficient experience with _all_ of them to
make this claim substantially stronger; I do have susbtantial experience
with most, and enough acquaintance with all, to hold this opinion rather
strongly) for application areas suitable for the latter (of course, if I
had to code, e.g., a Linux device driver, I _would_ use C -- that's not
within the application areas suitable for the various languages above).
Once-cool weirdish languages such as snobol, icon, etc, should not really
be considered for normal production use.

If one had infinite time, trying out all languages in the world would be
instructive (and, for some, fun). In practice, I would suggest to somebody
who wants to become a professional programmer to start with Python
(easiest to learn, yet powerful enough to be a constant companion
thereafter, whatever kind of programming one does); then add a lower-level
language, and I would suggest C because of its huge importance in both
practical open-source tools and existing literature about programming; then
add a mind-expanding one of the functional variety (I would suggest Haskell,
but some ML variant, or Clean, or Erlang, and others yet, might be favoured
by others); then some Scheme or other Lisp again mostly for instructional
purposes (chiefly to be able to study the great book, now freely available
online, known as SICP -- "Structure and Interpretation of Computer
Programs", by Abelson and Sussman). By the time this course of study was
finished, new languages might well have emerged, of course;-). And, also
of course, non-programming languages and non-languages issue should
also be studied -- relational databases and SQL, XML and related
technologies, networking and protocols, GUIs, algorithms and data
structures... (Python helps a lot in playing around with each of these
other important technologies and concepts, btw).

Somebody who wants to program but doesn't see producing programs as
an end in itself, but just as a means to whatever other ends, might be happy
just with Python (and a little pyrex on the side, perhaps -- but right know
I do not think there are texts to learn pyrex that don't assume you already
know some C) and whatever smattering of other computing technologies
they may happen to need in their application area.
Alex

[Limey Drink]

Alex, I don't know how you find the time to write such detailed replies :-)
but they're very welcome.

I have the book Learning Python, I think its an excellent book for learning
the core language but I have noticed on the O'reilly website a 2nd Edition
being released in December.

Has the core of the language changed very significantly from the version
covered in the first edition of Learning Python ?

By the way, I had no idea of your significance in the Python community,
since I have been looking for more information on Python I have noticed your
name on various books and websites so I appreciate information from a highly
experienced developer like yourself.

I am taking the first steps in developing/architecting quite a large project
and there are a lot of skills I need to aquire and also technologies to
choose for the job, this is not for the benefit of my current employer but
for myself :-) so I have alot of time to mess around and play with different
technologies and I can also actually enjoy writing the software without
silly timescales and sales/marketing types interfering.

Would you mind if I email you in the future if I am really stuck witha
problem ? looool :-)

Thanks again

"Alex Martelli" <al*****@yahoo. com> wrote in message
news:rs******** **************@ news1.tin.it...

Limey Drink wrote:
...

Thankyou very much Alex, this is the first time I have attempted to use
this group for information and I am very pleased with the prompt response.
once again thanks
You're welcome.

By the way, what do you think to Python with regards to productivity
benefits in general and also in comparison to other languages ?

Python, in my experience, is the most productive language over its wide
range of optimal applicability. pyrex, a variant of Python which it might
be still a bit too early to consider fully mature enough for production
use, extends Python's applicability to somewhat "lower levels", in a

sense.
I have seen people with particularly good mathematical mindsets do wonders
with functional programming languages, but I suspect those who'd be more
productive with those than with Python for typical applications would be a
tiny minority of the population. (This remains to be proven, but as a
working hypothesis it seems quite believable).

If you're after "tinkering" more than "production-level applications", don't need to consider the issues of group cooperation, or are slowly weaning
yourself from the complexity of perl and don't want the shock of going "cold turkey" into the simplicity of Python, Ruby may be a good compromise. Perl itself is too complicated, and other scripting languages (Javascript and
variants, VBScript, bash & variants, PHP, IMHO Tcl too though some Tcl'ers
will disagree, awk, etc) too feeble, to compete for productivity with Ruby
or Python.

Other languages which, depending on cultural background, available
tools, and problem areas, may be competitive with Python include Lisp
(Common, maybe the lesser-known ISO kind, Arc if it ever matures, Scheme,
...), Dylan, Smalltalk -- and no doubt others that I haven't had a chance
to try out yet.

Looking at the kind of languages that currently appear to rule the roost -- C, C++, Java, C#, Visual (and other kinds of) Basic, Object Pascal,
Fortran, Objective C, Ada, Cobol, Eiffel -- it does not seem to me that any of them can compete in terms of programmer productivity with the ones
listed above (I do not have sufficient experience with _all_ of them to
make this claim substantially stronger; I do have susbtantial experience
with most, and enough acquaintance with all, to hold this opinion rather
strongly) for application areas suitable for the latter (of course, if I
had to code, e.g., a Linux device driver, I _would_ use C -- that's not
within the application areas suitable for the various languages above).
Once-cool weirdish languages such as snobol, icon, etc, should not really
be considered for normal production use.

If one had infinite time, trying out all languages in the world would be
instructive (and, for some, fun). In practice, I would suggest to somebody who wants to become a professional programmer to start with Python
(easiest to learn, yet powerful enough to be a constant companion
thereafter, whatever kind of programming one does); then add a lower-level
language, and I would suggest C because of its huge importance in both
practical open-source tools and existing literature about programming; then add a mind-expanding one of the functional variety (I would suggest Haskell, but some ML variant, or Clean, or Erlang, and others yet, might be favoured by others); then some Scheme or other Lisp again mostly for instructional
purposes (chiefly to be able to study the great book, now freely available
online, known as SICP -- "Structure and Interpretation of Computer
Programs", by Abelson and Sussman). By the time this course of study was
finished, new languages might well have emerged, of course;-). And, also
of course, non-programming languages and non-languages issue should
also be studied -- relational databases and SQL, XML and related
technologies, networking and protocols, GUIs, algorithms and data
structures... (Python helps a lot in playing around with each of these
other important technologies and concepts, btw).

Somebody who wants to program but doesn't see producing programs as
an end in itself, but just as a means to whatever other ends, might be happy just with Python (and a little pyrex on the side, perhaps -- but right know I do not think there are texts to learn pyrex that don't assume you already know some C) and whatever smattering of other computing technologies
they may happen to need in their application area.
Alex

[smarter_than_you]

I can't compete with Alex for credibility, but for WIW -- Python and C
are your best bet. Python for high-level productivity, C for
interfacing with drivers, low-level libs, optimization, and so on.
Pyrex may be relevant in the future but I do not consider it mature
enough to trust on a biggish project.

Python + C will give you a very wide spread of capabilities. The
learning curve is at least 1/2 that of C/C++, possibly 1/3 or 1/4.
C++ in my experience is a 2-3 year trek to get to a productive level.
C is about a year, and Python is a few months.

YMMV - smy

"Limey Drink" <bh******@bhick ing.plus.com> wrote in message news:<Ze******* *************@w ards.force9.net >...

Alex, I don't know how you find the time to write such detailed replies :-)
but they're very welcome.

I have the book Learning Python, I think its an excellent book for learning
the core language but I have noticed on the O'reilly website a 2nd Edition
being released in December.

Has the core of the language changed very significantly from the version
covered in the first edition of Learning Python ?

By the way, I had no idea of your significance in the Python community,
since I have been looking for more information on Python I have noticed your
name on various books and websites so I appreciate information from a highly
experienced developer like yourself.

I am taking the first steps in developing/architecting quite a large project
and there are a lot of skills I need to aquire and also technologies to
choose for the job, this is not for the benefit of my current employer but
for myself :-) so I have alot of time to mess around and play with different
technologies and I can also actually enjoy writing the software without
silly timescales and sales/marketing types interfering.

Would you mind if I email you in the future if I am really stuck witha
problem ? looool :-)

Thanks again

"Alex Martelli" <al*****@yahoo. com> wrote in message
news:rs******** **************@ news1.tin.it...

Limey Drink wrote:
...

Thankyou very much Alex, this is the first time I have attempted to use
this group for information and I am very pleased with the prompt response.
once again thanks

You're welcome.

By the way, what do you think to Python with regards to productivity
benefits in general and also in comparison to other languages ?

Python, in my experience, is the most productive language over its wide
range of optimal applicability. pyrex, a variant of Python which it might
be still a bit too early to consider fully mature enough for production
use, extends Python's applicability to somewhat "lower levels", in a

sense.

I have seen people with particularly good mathematical mindsets do wonders
with functional programming languages, but I suspect those who'd be more
productive with those than with Python for typical applications would be a
tiny minority of the population. (This remains to be proven, but as a
working hypothesis it seems quite believable).

If you're after "tinkering" more than "production-level applications",

don't

need to consider the issues of group cooperation, or are slowly weaning
yourself from the complexity of perl and don't want the shock of going

"cold

turkey" into the simplicity of Python, Ruby may be a good compromise.

Perl

itself is too complicated, and other scripting languages (Javascript and
variants, VBScript, bash & variants, PHP, IMHO Tcl too though some Tcl'ers
will disagree, awk, etc) too feeble, to compete for productivity with Ruby
or Python.

Other languages which, depending on cultural background, available
tools, and problem areas, may be competitive with Python include Lisp
(Common, maybe the lesser-known ISO kind, Arc if it ever matures, Scheme,
...), Dylan, Smalltalk -- and no doubt others that I haven't had a chance
to try out yet.

Looking at the kind of languages that currently appear to rule the

roost --

C, C++, Java, C#, Visual (and other kinds of) Basic, Object Pascal,
Fortran, Objective C, Ada, Cobol, Eiffel -- it does not seem to me that

any

of them can compete in terms of programmer productivity with the ones
listed above (I do not have sufficient experience with _all_ of them to
make this claim substantially stronger; I do have susbtantial experience
with most, and enough acquaintance with all, to hold this opinion rather
strongly) for application areas suitable for the latter (of course, if I
had to code, e.g., a Linux device driver, I _would_ use C -- that's not
within the application areas suitable for the various languages above).
Once-cool weirdish languages such as snobol, icon, etc, should not really
be considered for normal production use.

If one had infinite time, trying out all languages in the world would be
instructive (and, for some, fun). In practice, I would suggest to

somebody

who wants to become a professional programmer to start with Python
(easiest to learn, yet powerful enough to be a constant companion
thereafter, whatever kind of programming one does); then add a lower-level
language, and I would suggest C because of its huge importance in both
practical open-source tools and existing literature about programming;

then

add a mind-expanding one of the functional variety (I would suggest

Haskell,

but some ML variant, or Clean, or Erlang, and others yet, might be

favoured

by others); then some Scheme or other Lisp again mostly for instructional
purposes (chiefly to be able to study the great book, now freely available
online, known as SICP -- "Structure and Interpretation of Computer
Programs", by Abelson and Sussman). By the time this course of study was
finished, new languages might well have emerged, of course;-). And, also
of course, non-programming languages and non-languages issue should
also be studied -- relational databases and SQL, XML and related
technologies, networking and protocols, GUIs, algorithms and data
structures... (Python helps a lot in playing around with each of these
other important technologies and concepts, btw).

Somebody who wants to program but doesn't see producing programs as
an end in itself, but just as a means to whatever other ends, might be

happy

just with Python (and a little pyrex on the side, perhaps -- but right

know

I do not think there are texts to learn pyrex that don't assume you

already

know some C) and whatever smattering of other computing technologies
they may happen to need in their application area.
Alex

[Christopher Koppler]

"Limey Drink" <bh******@bhick ing.plus.com> wrote in message news:<Ze******* *************@w ards.force9.net >...

Alex, I don't know how you find the time to write such detailed replies :-)
but they're very welcome.
Oh, that's not Alex himself writing these... He's programmed a bot to
do that ;-)

I have the book Learning Python, I think its an excellent book for learning
the core language but I have noticed on the O'reilly website a 2nd Edition
being released in December.

Has the core of the language changed very significantly from the version
covered in the first edition of Learning Python ?

Everything in the first edition is still valid; the core has been
extended enough, however, that a new up-to-date edition is definitely
a good thing.

--
Christopher

[Alex Martelli]

Limey Drink wrote:

Alex, I don't know how you find the time to write such detailed replies
:-) but they're very welcome.
Glad to be of help.

I have the book Learning Python, I think its an excellent book for
learning the core language but I have noticed on the O'reilly website a
2nd Edition being released in December.

Has the core of the language changed very significantly from the version
covered in the first edition of Learning Python ?
Yes, the current Python (2.3) is substantially larger, even at its "core",
than the 1.5.2 version described in the current (old) edition of "Learning
Python". The effect of some additions has been to marginalize idioms and
techniques previously prominent. In particular, list comprehensions have
further marginalized lambda, map, reduce, filter; the apply built-in is
basically obsolete thanks to the *args and **kwds forms of argument
passing in function calls; nested lexical scopes make the good old idea
of "foo=foo" ``default arguments'' used for name injection into inner
scopes somewhat quaint and of little practical interest; ... Not to
mention the reorganization of OO into "new-style classes", a much clearer
and simpler systematization than the "classic classes" that also remain
in the language (and indeed are the default, for backwards compatibility).

To teach the language today, one does not want to dwell on the way the
language was five years ago, and on features that remain in the language
just because of backwards compatibility constraints. The parts of the
language that you should normally use in writing new code are in fact no
larger than the ones you should have used in Python 1.5.2 -- but they
ARE different to some measurable extent, say (hard to gauge) with some
75% overlap and 25% difference. One day, when we can break _some_
backwards compatibility -- presumably at the release of 3.0, maybe 3
years from now -- many of the "just backwards compatiiblity" ideas will
be deprecated or removed; Guido van Rossum is on record as saying that
3.0 will be about simplification and getting back to "one obvious way
to do it", removing "legacy", backwards-compatibility-only stuff.

Would you mind if I email you in the future if I am really stuck witha
problem ? looool :-)

Actually, I would: I prefer to discuss things on the newsgroup, since
this way one gets the benefit of multiple voices. No single "expert"
has ALL the answers (not even me, nach!), and the give-and-take of
debate here often proves more productive than just getting some single
oracular response would. Further, discussion here can benefit others
beyond the single person who's posing a question, so there are larger
returns for the same amount of effort.
Alex

[Cameron Laird]

In article <rd************ **********@news 2.tin.it>,
Alex Martelli <al***@aleax.it > wrote:

[Limey Drink]

Alex Martellibot ? :-)

Would you mind if I email you in the future if I am really stuck witha
problem ? looool :-)

Actually, I would: I prefer to discuss things on the newsgroup, since
this way one gets the benefit of multiple voices. No single "expert"
has ALL the answers (not even me, nach!), and the give-and-take of
debate here often proves more productive than just getting some single
oracular response would. Further, discussion here can benefit others
beyond the single person who's posing a question, so there are larger
returns for the same amount of effort.

Actually, I completely agree with this, I think I said this before I
actually thought about it, there has been such an excellent response to my
queries on here already for me to realize I would not be gaining anything
from speaking to you directly, also as you pointed out other people can
benefit from the input too :-), just as I have benefitted from the responses
to posts by other Python users on here.

Thanks