Python is a mini C? 
Author Message
 Python is a mini C?

Much to my horror, this point has come up quite a few times recently -
twice this week.

A couple of non-professional programmers (ie, people for whom programming is
not their primary job) have described python as a mini C, and more
interestingly (and horrifyingly) have said that the "P" language is far far
easier to learn.

After much digging, I found that at least one of these users has said that
Python gets better as the problem gets larger, but they still find it
preferable to use other languages for anything that is small or trivial.
And this is with me in there ear all the time :-)

To my mind, this is a bit of a problem.  My gut feeling is that we - the
Python community - are perpetuating that.

A case in point.  One of these people (a good friend, actually) has alot of
problems with objects, and object notation.  Whenever he deals with anything
with a "." in the name, his eyes gloss over.  He just doesnt get the OO
concept, and being a non-programmer, really doesnt want to.  His problems
dont have anything to do with objects (from his POV, anyway) why are we
forcing them on him.  He is sure that people like me just _love_ objects,
but he doesnt care - he just wants his servers to deliver mail when they are
supposed to!

Side-track:  Urban legend has it that Microsoft themselves capitalize on
this.  When VC1 was being built, Borland had well over 50% of the windows
compiler market.  They were also way ahead technically.  MS research found
that the problem was _not_ C++ users wanting templates, or RTTI, or anything
like that - the _real_ problem was programmers moving into C++ at _all_.  So
instead of spending time adding templates and many other ANSI features (that
I am _still_ yet to use in some cases!) they developed the code generating
Wizards.
ie, they lowered the barriers preventing users adopting C++ in the windows
world, and the users flooded in.

I have only one or 2 specific proposals, but the main point I am trying to
make is that we must make sure we "pitch" Python at the appropriate place.
If we want Python to succeed for Professional programmers, then we can stick
with what we are doing.  If we want Python to succeed for the breed of
people who see programming as a necessary evil (and that probably describes
most CGI type programmers and network administrators, for example) then we
need to focus our stuff better.

Concrete examples:
* All examples for absolute beginners should use "from module import *".  Us
arrogant types consider this bad coding.  Mere mortals consider it readable
and far far less verbose and confusing.
* Stuff like "int(string_val)" do the right thing.  I realize this is in
Python 1.5, but I recall it was a battle.  A mind-set change is needed.
* Give a few ways to do things.  String quotes is an example we have.  "<>"
or "!=" is another.  Lets have more!  Introduce more aliases for certain
common functions (eg, string.trim == string.strip, etc).

In a nutshell, maybe we need to keep our user base more in mind than the
"purity" of the language.  The most extreme view is that who cares about a
completely pure language when no one is using it - instead they are using
the language that drove many of us here - that "P" language.

[Maybe all the above could be done with a beginners "site.py", which sets up
aliases, does lots of "from common_module import *", etc - I dont care how,
just about the result!]

Not trying to sound gloomy or that we have a lost cause, but hopefully
raising some points which are real barriers.  Being a "professional
programmer", I found it strange, and even sacreligious, that someone could
assert P??l could be better for _anything_ other than heavy duty string
processing.  But maybe we _do_ need to face the reality that we _dont_ cater
to that end of the market to well...

Hopefully just raising points for discussion, and not a flame-fest...

Mark.



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

> A couple of non-professional programmers (ie, people for whom programming is
> not their primary job) have described Python as a mini C, and more
> interestingly (and horrifyingly) have said that the "P" language is far far
> easier to learn.

This sounds odd. What background do they have? I can understand
that people who know unix recognize a lot in Perl (I suppose
that's your "P" language). For people without associations that
help them with Perl (Unix shell, C, sed, awk) I was certainly of
the opinion that Python would be a lot simpler, but maybe I have
been fooling myself.

A big plus for Perl is the documentation: Both the man-pages,
the quick refernce guide (my favourite ;) and Programming Perl
are high quality documents, and there are a lot of other books
as well.

Considering the installed base I also assume that the average
perl hacker will find more source examples to learn from. Although
I think it's a bit easier to understand other peoples Python code
compared to other peoples Perl code.

Quote:
> After much digging, I found that at least one of these users has said that
> Python gets better as the problem gets larger, but they still find it
> preferable to use other languages for anything that is small or trivial.
> And this is with me in there ear all the time :-)

Maybe that's the problem... Perhaps you confuse them? ;-)

Still, isn't the real reason that they knew perl before they learnt
python? They habe long forgotten what a struggle it was in the
beginning, or if they remember, they don't want to go through it
again.

When I first ran across perl, I quickly felt that I liked it, but it
did confuse me. It certainly had more 'magic' in it than any other
language I had seen.

Quote:
>A case in point.  One of these people (a good friend, actually) has alot of
>problems with objects, and object notation.  Whenever he deals with anything
>with a "." in the name, his eyes gloss over.

Actually, when I think of it, there was a certain threshold... Once
upon a time, I who had programmed quite a bit Turbo Pascal version 5
without any objects whatsoever started working with the Object Pascal
in version 6. I had to write code based on objects someone else had
made, and it certainly took me some time to grasp those concepts.

After that I hadn't really done a lot of OO programming until I ran
into Python, but maybe that struggle with Borlands Object Pascal made
it easier to grasp Python than it would otherwise be. This is
certainly a conseptual obstacle that you have to climb, but once you
are there it's all very obvious.

Something that might make it more confusing is that Python uses this
in two different ways. At least it might seem so for the user, since
it isn't obvious that modules are objects just like lists.

In the following:

Quote:
>>>list = [ 'a', 'c', 'b']
>>>list.sort()
>>>import string
>>>string.join(list)

the dot-notation is used in two radically different ways. The second,
string.join(list) could be compared to /bin/ls or c:\win\notepad.exe.
You have to tell the computer where to find 'join()'. I don't think
this is more complicated to understand than file hierarchies.

The first use 'list.sort()' is much more alien for people used to
languages like pascal, C or perl. Why don't you write sort(list)?
Here, I think we have more of a threshold. (As noted below, the
dot-notation for modules can be avoided anyhow using 'from'.)

Naturally, there is for us OO-lovers :-) a beauty in this, and we
really want people to undrstand how neatly it all fits together.
I think the issue is that we have to much enthusiasm and to little
pedagogical skills when we try to explain this.

Maybe some really simple OO primer bundled with the Python docs
could fix this. Maybe this should avoid the two words 'object'
and 'oriented'.

Quote:
> Concrete examples:
> * All examples for absolute beginners should use "from module import *".  Us
> arrogant types consider this bad coding.  Mere mortals consider it readable
> and far far less verbose and confusing.

Even if it wasn't a matter of 'polluting' namespace, I think
"from module import this, that, another" is better. '*' says very
little, but by telling what you import from the various modules
you help a bit. Naturally "import split, join from string" would
have been easier to understand and remember, but I won't suggest
that kind of syntax changes here.

Quote:
> * Give a few ways to do things.  String quotes is an example we have.  "<>"
> or "!=" is another.  Lets have more!  Introduce more aliases for certain
> common functions (eg, string.trim == string.strip, etc).

Do you really think that the "there's more than one way to do it"
approach would be a help? I think it might lead to even more confusion.

Quote:
> In a nutshell, maybe we need to keep our user base more in mind than the
> "purity" of the language.  The most extreme view is that who cares about a
> completely pure language when no one is using it - instead they are using
> the language that drove many of us here - that "P" language.

But maybe people are different and maybe Perl fits some people better
and Python is better for others. I don't think it's better for Python
if it turns into another Perl. If it would, It's rather go with the
original.

        Magnus



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

> Concrete examples:
> * All examples for absolute beginners should use "from module import *".  Us
> arrogant types consider this bad coding.  Mere mortals consider it readable
> and far far less verbose and confusing.

Some months ago I wrote a little something "How to start programming
with Tkinter". My idea was that beginning Tkinter programmers should be made
aware of some resources before starting to reinvent several wheels. While
writing my text I dawned upon me that this approach was futile as
programmers want to see their new extension in action as soon as they have
finished the installation hasles.

A good demo browser would have a far better effect than any MIND THIS text.
Thus beginners can become acquainted with the features of the language without
having to toil through manuals or fight their way through the ./Demo
directory ("What ./Demo directory? I can't find it in my XXX
distribution!").

Basically, I want something like the PyTix or Pmw demo browser for the
entire set of python demos. With this one can pick a demo from a listbox,
see what it does upon execution and optionally look at the code.

So far I have included FontText in the Pmw browser for more attractive code
viewing and I have rewritten most of the ./Demo/tkinter/matt examples to be
executable from the browser.

Further extensions should include:
  - directory browsing.
  - display stdout, stderr for non-Tkinter code.
  - keyword and name index of all demos.
  - links to relevant manpages.

(I consider this important for our community, but not of very high priority
considering other projects that I am running. Follow-ups in this thread may
motivate me to renice it.)

Quote:
> * Give a few ways to do things.  String quotes is an example we have.  "<>"
> or "!=" is another.  Lets have more!  Introduce more aliases for certain
> common functions (eg, string.trim == string.strip, etc).

> In a nutshell, maybe we need to keep our user base more in mind than the
> "purity" of the language.  The most extreme view is that who cares about a
> completely pure language when no one is using it - instead they are using
> the language that drove many of us here - that "P" language.

I disagree strongly. It might well be that beginning pythoneers like the
opportunity to code in their own favorite lexicon (I use '<>' instead
of '!='; I learned Pascal before C). When the language allows a baroque
lexicon, however, the readability of code will be negatively affected.
One wonderful thing about python code today is that it is eminently
readable. The result is simple maintenance and modification by third
parties.

Perhaps we can compromise by introducing a "python preprocessor", that
translates code following different lexical preferences to the one and only
GNF (Guido Normal Form).

cjr

--



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

> "purity" of the language.  The most extreme view is that who cares about a
> completely pure language when no one is using it - instead they are using
> the language that drove many of us here - that "P" language.

  I guess I qualify as naive programmer that Mark has described. Well, I
love objects and I think coding/debugging it is easier than other wise,
even with not so well implemented. Anyway, I tried to convert some of
our programmers to Python, so they can help me out to some degree. Well,
after looking at VB5's Visual environment, I know I was in trouble. Even
with best core, Python lacks VB5's tools. If one never saw it, it just
has to be experienced. All they are is just productivity tools that just
have been implemented well.
  Most of growth will come from Windows area in the future for all
languages. I chose Python due to elegence of structure, OO, math, and
command interpreter; however, most people will choose their language for
ease of use and good documentation, which leaves Python in a bit a
trouble. I really had hard time following Win installation, adding
Numerics in Unix, NetCDF in Unix, DCOM extention, etc...
  Approaching this from business pt of view. My enturpreneurship
professor said that he would always bet on good management team, who can
turn any decent idea into solid product, rather than a poor management,
who could easily{*filter*}up even the best ideas. Gates/Jobs ring any
bells?
  Oops, too close to mkt open, gotta go in this crazy mkt.
Thanks for reading this babble,

--
*******************************************************************

  * Expressed opinions are often my own, but NOT my employer's.
"I feel like a fugitive from the law of averages."    Maudin
"Miracle(n)- An instance of few standard deviations," Me
*******************************************************************



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

> A couple of non-professional programmers (ie, people for whom programming is
> not their primary job) have described Python as a mini C, and more
> interestingly (and horrifyingly) have said that the "P" language is far far
> easier to learn.

People making this statement should have tried both. Do you happen to know
which one they learned first? Most people I know considered their second
language more difficult to learn, because they had to "unlearn" features
that they considered universal.

Quote:
> A case in point.  One of these people (a good friend, actually) has alot of
> problems with objects, and object notation.  Whenever he deals with anything
> with a "." in the name, his eyes gloss over.  He just doesnt get the OO
> concept, and being a non-programmer, really doesnt want to.  His problems

Fine, he can do Python without them if he prefers to. Of course all
the available literature tells you that OO is the way to go...

Quote:
> I have only one or 2 specific proposals, but the main point I am trying to
> make is that we must make sure we "pitch" Python at the appropriate place.
> If we want Python to succeed for Professional programmers, then we can stick
> with what we are doing.  If we want Python to succeed for the breed of
> people who see programming as a necessary evil (and that probably describes
> most CGI type programmers and network administrators, for example) then we
> need to focus our stuff better.

So what do "we" want? I am not sure the answer is clear at all.
Neither is it clear that a single language can serve both groups as
well. Maybe we *should* stick to the current strategy and let the
others use Perl. What's the problem? We are not missionaries.

Quote:
> Concrete examples:
> * All examples for absolute beginners should use "from module import *".  Us
> arrogant types consider this bad coding.  Mere mortals consider it readable
> and far far less verbose and confusing.

Up to a point. And not all people are able to recognize for themselves
when such "quick hack" approaches should be given up. I live in a world
where most programs, even big ones, are written by people who were
taught "simplified" beginners' techniques, and who stick to them. The
result is a big mess.

Quote:
> * Give a few ways to do things.  String quotes is an example we have.  "<>"
> or "!=" is another.  Lets have more!  Introduce more aliases for certain
> common functions (eg, string.trim == string.strip, etc).

And not so far in the future we will have seven white-space removers in
string, with three of them representing similar, but different functionality
and the remaining ones being aliases. No, thanks, libraries are
complex enough as they are!

Quote:
> In a nutshell, maybe we need to keep our user base more in mind than the
> "purity" of the language.  The most extreme view is that who cares about a

Our user base or that of some other language? It may simply be that
Python and Perl appeal to people with different preferences, which
is nothing to be ashamed of.
--
-------------------------------------------------------------------------------

Laboratoire de Dynamique Moleculaire   | Tel.: +33-4.76.88.99.28
Institut de Biologie Structurale       | Fax:  +33-4.76.88.54.94
41, av. des Martyrs                    | Deutsch/Esperanto/English/
38027 Grenoble Cedex 1, France         | Nederlands/Francais
-------------------------------------------------------------------------------


Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

>A couple of non-professional programmers (ie, people for whom programming is
>not their primary job) have described Python as a mini C, and more
>interestingly (and horrifyingly) have said that the "P" language is far far
>easier to learn.

        That's astounding.  While Perl may be more convenient for
little snippets of code, can these non-professional programmers really
find it easier?  Or do they simply never use functions or attempt to
make data structures at all?  In which case, perhaps there should be a
custom site.py available, as suggested below.

Quote:
>Concrete examples:
>* All examples for absolute beginners should use "from module import *".  Us
>arrogant types consider this bad coding.  Mere mortals consider it readable
>and far far less verbose and confusing.

        Hmmm...

Quote:
>* Stuff like "int(string_val)" do the right thing.  I realize this is in
>Python 1.5, but I recall it was a battle.  A mind-set change is needed.

        Perhaps the fundamental sticking point here is between people
like their language to enforce restrictions and sanity-checks, and
those who like automatic conversions.  (c.l.p regulars know that I'm
firmly in the first camp.)

        Maybe we just need more introductions to Python, written by
people with different biases.  For example, I think starting people
with 'from foo import *' is a mistake, because it's only a matter of
time before they get burnt by a symbol conflict (both modules defining
their exceptions as 'error' or whatever).  Note that the Tutorial
mentions 'import *' exactly once, and never uses it again.  

        But that's just my preference; maybe we need introductions
written by people with differing viewpoints and styles.

Quote:
>* Give a few ways to do things.  String quotes is an example we have.  "<>"
>or "!=" is another.  Lets have more!  Introduce more aliases for certain
>common functions (eg, string.trim == string.strip, etc).

        I don't believe tweaking the language can make the language
more attractive to new users, and it'll never end until the language
becomes exactly what they're used to.  

Quote:
>[Maybe all the above could be done with a beginners "site.py", which sets up
>aliases, does lots of "from common_module import *", etc - I dont care how,
>just about the result!]

        Good idea.  Perhaps such a site.py could be included under a
different name, and the tutorial could mention its existence.  Or
perhaps site.py could automatically run this beginner's module if some
condition was met (an environment variable?).  

        Andrew Kuchling

        http://starship.skyport.net/crew/amk/



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:


> >A couple of non-professional programmers (ie, people for whom programming is
> >not their primary job) have described Python as a mini C, and more
> >interestingly (and horrifyingly) have said that the "P" language is far far
> >easier to learn.

>         That's astounding.  While Perl may be more convenient for
> little snippets of code, can these non-professional programmers really
> find it easier?  Or do they simply never use functions or attempt to
> make data structures at all?  In which case, perhaps there should be a
> custom site.py available, as suggested below.

At my previous job, one of the programmers (who somehow got selected for Java
programming.  I think the managerial decision was "He knows HTML, and
magazines keep talking about Java and Web pages, therefore he should do Java)
could NOT handle abstract notions like objects.  His mind just would not
accept them.  For example, we had an application that ran a search against a
full-text database (powered by Glimpse) comprising of a Java Applet connected
to a Python socket server that interfaced to the Glimpse datastores.  The
applet needed to get back information like the title of the full document, the
URL to that document, and some summary lines about the document pertaining to
the search.  BOOM!  Right away I recognized this as a classic Struct or Record
situation and tried to show him how the following construct would save his life:

class ResultDataObject {
        String title;
        String link;
        String[] summarylines;

Quote:
}

(or something to that affect.  My Java is thankfully a little rusty).  He
COULD NOT understand.  For months even.  I had to code this and show him how
to put values in.  Even for weeks afterwards, if there was a bug in his
program he blamed this simple construct because he could not fathom what I was
doing.  He couldn't realize that he was doing something like this everytime he
wrote an Applet.  (He trusted the applet code because it came from a book.  He
just never learned what the code was really doing).  Basically, something in
his mind couldn't handle abstractions.  I think he's getting into assembly
code now :-).  He could never understand my Python code.  Not because it was
bad code, but because he couldn't see where stuff was coming from.  His mind
just refused to handle it.

The main Perl programmer at the same company who was responsible for a lot of
our very very low level digging-in-the-bowels-of-a-hacked-unix-system code was
similar.  He kept the O'Reilly books around him at all times, coded night and
day, and was suddenly shocked (after a couple years of programming) that he
could make pass parameters to his own functions.  He thought he had found
objects because he could finally see ways of reusing his code (his previous
idea of reuse involved copy/paste, or modifying and saving the file under a
new name).

He too couldn't grasp my Python code.  (And needless to say, I'm *much*
happier here at Digital Creations ;-).

Point being: some people would have to go through way too huge of a paradigm
shift to understand the stuff that many of us on this list do automatically.
Changing Python to accomodate these people would be like asking Larry Wall to
take the &%${};s/qw()/g<X>die out of Perl so Python-like people could use it.
I'd much rather use Python than english-mode Perl because I think more like
Python 9 out of 10 doctors of the week.  If someone's happy coding i486
assembly, well, better him than me :).

Quote:
>         Maybe we just need more introductions to Python, written by
> people with different biases.  For example, I think starting people
> with 'from foo import *' is a mistake, because it's only a matter of
> time before they get burnt by a symbol conflict (both modules defining
> their exceptions as 'error' or whatever).  Note that the Tutorial
> mentions 'import *' exactly once, and never uses it again.

>         But that's just my preference; maybe we need introductions
> written by people with differing viewpoints and styles.

I'm for this.  I've seen many books in my lifetime like "Macintosh for MS-DOS
users" and vice-versa.  EMacs has ways of moving people over from Vi, and
there are many "Java for C programmers" books or sections of books.

Quote:

> >* Give a few ways to do things.  String quotes is an example we have.  "<>"
> >or "!=" is another.  Lets have more!  Introduce more aliases for certain
> >common functions (eg, string.trim == string.strip, etc).

>         I don't believe tweaking the language can make the language
> more attractive to new users, and it'll never end until the language
> becomes exactly what they're used to.

__shudder__  Then everything would probably become a satanic VB/Perl/Java
hybrid.  And i just got back from lunch.

--
"Green Tony squeeled and I'm off to Galaxy X"

                     http://www.digicool.com/



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?



Quote:

>People making this statement should have tried both. Do you happen to know
>which one they learned first? Most people I know considered their second

People will in general try to express things in familiar terms.  That's
just the way the world works...  Having been a serious C programmer for
over a decade, I can't imagine how anyone would make that comparison other
than that all they knew was C...

Personally, I happen to think of it as "a more efficient java", and
"perl designed by somone who knew something about language design."
I really like Java as a language, but it is SO expensive to run in
both memory and CPU cycles.  Plus, for long-running tasks, the Linux
JDK leaks all over the place...

Quote:
>Fine, he can do Python without them if he prefers to. Of course all
>the available literature tells you that OO is the way to go...

I do think that Python is a well designed language.  However, it doesn't
sound like it may be the best language for this person.  There are enough
languages out there that there's really no need to try to fit a round peg
into a square hole...

Quote:
>when such "quick hack" approaches should be given up. I live in a world
>where most programs, even big ones, are written by people who were

That's the biggest thing that I see graduates having to unlearn once they
leave school.  They're still in the attitude of having to hack out a
program by the end of the week that they *NEVER* have to look at again.
The programming class I took I was practically BEGGING to do a large
project that we'd work on pieces until the end of the semester.

I was wanting to write a text editor.  Instead we wrote a "mouse
searching the maze for cheese" which demonstrated screen I/O, a
syntax hilighter which did rudimentary parsing, etc...  I can't
think of a SINGLE program that was more than a couple of printed
pages long, and none of them were EVER used again.

Quote:
>> In a nutshell, maybe we need to keep our user base more in mind than the
>> "purity" of the language.  The most extreme view is that who cares about a

I couldn't disagree more.  I like that Python is relatively "pure".
Or I guess it would be more appropriate to say that I really DISlike
that Perl is "impure".

Quote:
>It may simply be that Python and Perl appeal to people with different
>preferences, which is nothing to be ashamed of.

Perl can do some things VERY nicely.  However, a lot of things in Perl
are kind of obtuse from my standpoint.  It's just not a very consistant
language in some ways.  I do love the ease with which you can write
things to process input using regular expressions...

Sean
--
 Unix actually IS user friendly -- it's just very picky about whom it
 calls its friend.

URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

>A couple of non-professional programmers (ie, people for whom programming is
>not their primary job) have described Python as a mini C, and more
>interestingly (and horrifyingly) have said that the "P" language is far far
>easier to learn.

Is this due, in their minds, to the fact that Perl has a mostly C like
syntax?

I find that most people who prefer Perl to Python do so because:

[Select any one, two, or more ;->]

1) They have a background in Awk/Sed/C/Shell programming on Unix.
2) They do a lot of Perl for heavy duty, high speed text processing.
3) They have no exposure to the OO paradigm.
4) They got bitten by the "whitespace blocking bug" (Sorry, Guido, but
   so far, every one of my newbies has, at least once, been bitten by
   mixing spaces and tabs) or by unexpected behaviors due to not
   understanding name space issues.

Quote:
>After much digging, I found that at least one of these users has said that
>Python gets better as the problem gets larger, but they still find it
>preferable to use other languages for anything that is small or trivial.

Me, too.  This is no reflection on Python, though.  There is no real need
for Python to be "The-Only-Language".

Quote:
>A case in point.  One of these people (a good friend, actually) has alot of
>problems with objects, and object notation.

Point 3, yes? ;->

Personally, I probably wouldn't have started using Python if it hadn't
been OO, but YMMV.

Quote:
>Whenever he deals with anything
>with a "." in the name, his eyes gloss over.

I do sometimes long for an Objective C style message syntax, if for no
other reason than to drive home the "message-is-not-the-method" point which
seems to be a major hurdle for recovering. . . er, *transitioning* (yeah!
that's the ticket!) non-OOP C++ users (if that last statement seems
self-contradictory, well. . .).

You'd be amazed at the responses I get when I show my students example
programs that invoke a method named X, using message Y!

Quote:
>He just doesnt get the OO
>concept, and being a non-programmer, really doesnt want to.

This is a real pity.  Perhaps instead of using the O word, you could just
tell him that the keyword for struct, in Python, is class. . . ;->
[See below].

Quote:
>His problems
>dont have anything to do with objects (from his POV, anyway) why are we
>forcing them on him.

If he never went near a library module, he wouldn't need to "see" objects,
but it is indeed true that OOP pokes its head up when you import a
library module.

Quote:
>Side-track:  Urban legend has it that Microsoft themselves capitalize on
>this.  When VC1 was being built, Borland had well over 50% of the windows
>compiler market.  They were also way ahead technically.  MS research found
>that the problem was _not_ C++ users wanting templates, or RTTI, or anything
>like that - the _real_ problem was programmers moving into C++ at _all_.  So
>instead of spending time adding templates and many other ANSI features (that
>I am _still_ yet to use in some cases!) they developed the code generating
>Wizards.
>ie, they lowered the barriers preventing users adopting C++ in the windows
>world, and the users flooded in.

<MS flame>
Does this, or does this NOT explaing a LOT! ;->

[Windows.  The OO OS written by people who don't know what OO is. . .]
</MS flame>

Ok, there are Windows users in this group, so please accept the above
as just what it is: personal opinion driven by to many bad-MS days.

Quote:
>I have only one or 2 specific proposals, but the main point I am trying to
>make is that we must make sure we "pitch" Python at the appropriate place.

As a hack for the extremely Python challenged, how about writing some
"wrapper" modules that pull apart existing library modules to give them
a "procedural" interface?

Say:
-----------------------------------------------------------------------------
# Orginal module looks like this.

class SomeClass:
        def __init__(self):
                ...

        def func1(self, a, b):
                ....

-----------------------------------------------------------------------------
# Wrapper module looks like this.

from original_module import *

initSomeClass = SomeClass.__init__
func1 = SomeClass.func1

Quote:
>If we want Python to succeed for Professional programmers, then we can stick
>with what we are doing.  If we want Python to succeed for the breed of
>people who see programming as a necessary evil (and that probably describes
>most CGI type programmers and network administrators, for example) then we
>need to focus our stuff better.

Personally, I'd prefer to leave Python alone, and change the users! ;-.

But whatdoyou expect from me, eh?

Quote:
>Concrete examples:
>* All examples for absolute beginners should use "from module import *".  Us
>arrogant types consider this bad coding.  Mere mortals consider it readable
>and far far less verbose and confusing.
>* Stuff like "int(string_val)" do the right thing.  I realize this is in
>Python 1.5, but I recall it was a battle.  A mind-set change is needed.

I find that usually, the battles are well worth the cost.  The "battles"
are really engineering brain storm sessions done in slow-time on the
net (for those who, up to now, valued their naivete re: engineers and
the design process, I apologize :-), giving us, if not the best solution,
at least one of the better ones.

Quote:
>* Give a few ways to do things.  String quotes is an example we have.  "<>"
>or "!=" is another.  Lets have more!  Introduce more aliases for certain
>common functions (eg, string.trim == string.strip, etc).

One of the arguments advanced for choosing Python over Perl (just as an
example) is the "orthogonality" of the language.

Your point of view is more closely aligned with Larry Walls: provide many
different mechanisms for accomplishing the same task, in accordance to
the way "natural languages" are used and evolve.

Quote:
>In a nutshell, maybe we need to keep our user base more in mind than the
>"purity" of the language.  The most extreme view is that who cares about a
>completely pure language when no one is using it - instead they are using
>the language that drove many of us here - that "P" language.

One solution to the problem you address, would be to give these poor
souls the bare minimum OO orientation, so they can use the libraries:

1) class A:
       def __init__(self):
           self.field1 = ""

"Forget OO, this is just a way of defining a structure that has default
 values for every field, except that in Python, you have the added
 advantage of being able to add and subtract thingies from the structure at
 run time!

 Just make sure you stick all of your fields underneath the __init__
 line."

2) instance = Class()

"Don't sweat it, this is just shorthand for:

 Allocate a new structure of type Class, and initialize all fields
 to the default values specified."

3) instance.message( parameters )

"Weird syntax, but all this really means is the equivalent of:

 message(instance, parameters)

Python sure is simple, eh?"

Believe it or not, I did just that with one rather recalcitrant
student, then very slowly hacked away at 'im until he ended up,
almost behind his back, having a basic understanding of OOP.

Quote:
>[Maybe all the above could be done with a beginners "site.py", which sets up
>aliases, does lots of "from common_module import *", etc - I dont care how,
>just about the result!]

It's easier, IMHO, to simply orient new users.

Quote:
>Not trying to sound gloomy or that we have a lost cause, but hopefully
>raising some points which are real barriers.  Being a "professional
>programmer", I found it strange, and even sacreligious, that someone could
>assert P??l could be better for _anything_ other than heavy duty string
>processing.

Perl is more tightly tied to Unix.  This makes Perl a good scripting
language.  If you want cross platform portability, of course, Python
is better.  You may (probably do) disagree, and I certainly do switch
to Python when the task gets large, or requires complex data structures.

Quote:
>But maybe we _do_ need to face the reality that we _dont_ cater
>to that end of the market to well...

I suspect that OO is going to become more "natural" for programmers as
time goes by.  But is it really an issue?  I mean, when you get right
down to it, you're really talking about a temporary problem, one that
might be better solved by traning, instead of hacking Python around.

<flame proof suit>
I just wish the name-sake book *started* with OOP training, instead of
leaving it to much later.  |-<

No insult intended.
</flame proof suit>

I agree, no flames on this, please. . .

YMMV, you are entitled to your opinion and all that.

John S.



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?


Quote:
>    Apparently we need both a K&R-style document, that covers
> everything very concisely, and a friendly guide to programming that
> starts with explaining what variables and functions are.  Books about
> Logo are probably a good model for the introductory text.

SICP in Python, anyone? Or is that expecting to much of the target
audience?

        <mike

--
Do NOT reply to the address in the From: header. Reply to mwm instead of
bouncenews at the same machine. Mail to bouncenews will be returned with
instructions on reaching me. Sending unsoliticed email I consider commercial
gives me permission to subscribe you to a mail list of my choice.



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

>In a nutshell, maybe we need to keep our user base more in mind than the
>"purity" of the language.  The most extreme view is that who cares about a
>completely pure language when no one is using it - instead they are using
>the language that drove many of us here - that "P" language.

Guess the real problem here is to figure out what "our user base"
really is...

<wrote a long rant on this, but I'll spare you from that today>

Personally, I think the really interesting target group is professional
organizations. The software industry spends time writing way too
lousy software; using a dynamic and easy to grok language like
Python could help us all spend more time on making the products
really good, and less time struggling with the tools. If non-pro-
grammers find Python useful, that's fine; if they prefer Perl, so
what?

That doesn't mean that everything's just fine; but I think it would
be much better to spend the energy on development environments,
including intelligent help systems, templates, wizards, etc, than on
these endless threads on how Python could be tweaked in one way
or another...  on the other hand, I've just started a company to work
on the former issues, so nevermind ;-)

Cheers /F

http://www.pythonware.com



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:
> This sounds odd. What background do they have? I can understand
> that people who know unix recognize a lot in Perl (I suppose
> that's your "P" language). For people without associations that
> help them with Perl (Unix shell, C, sed, awk) I was certainly of
> the opinion that Python would be a lot simpler, but maybe I have
> been fooling myself.

I don't think so. I spent a lot of effort learning Perl and found it difficult
because it was so damn quirky. Python is a nice unification of the
"standard features" from modern programming languages. As those
programming languages become more and more popular, Python will seem
easier and easier to learn. I don't think that we should back away from
object-centricity just as the rest of the world is getting educated about
it. I don't think it is inherently difficult.

 Paul Prescod



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?


Quote:
>Anyway, I tried to convert some of
>our programmers to Python, so they can help me out to some degree. Well,
>after looking at VB5's Visual environment, I know I was in trouble. Even
>with best core, Python lacks VB5's tools. If one never saw it, it just
>has to be experienced. All they are is just productivity tools that just
>have been implemented well.

I agree, though on the Mac, the difference is not so great.  MacPython is
relatively easy to install (though it does require more steps than your
usual Mac application), and Just van Rossum has developed a beautiful
Python IDE.  I think we should encourage him in this effort, and make it
part of the standard distribution ASAP.  Perhaps folks on other platforms
can follow his example.

Another point is the lack of decent tutorials for nonprogrammers.  I have a
friend who recently wanted to learn to program, just to have some idea what
it's like.  I tried to sell him on Python, but since he couldn't find any
hold-him-by-the-hand tutorials for complete programming novices, he ended
up buying a "Discover Programming in C" book and IDE instead.

Of course, the docs contain a tutorial, but it's geared more towards
programmers of other languages just migrating to Python.  And I have my
Python for Newbies page, but it's really just a handful of examples, rather
than a tutorial.

Finally, the lack of a decent standard GUI is also a discouraging factor.
Many beginning programmers want to make games or some such, or at least
make programs that look like the standard apps for their system, and this
is very difficult in Python.  But I've heard that Python 1.5 will contain
Tk8.0, which is a significant improvement over earlier versions.  It's
still hard to compete with Java on this score, though (despite Java's
general suckiness).

My $.02 worth...
-- Joe

,------------------------------------------------------------------.
|    Joseph J. Strout           Department of Neuroscience, UCSD   |

`------------------------------------------------------------------'



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?


Quote:
>Another point is the lack of decent tutorials for nonprogrammers.  I have a
>friend who recently wanted to learn to program, just to have some idea what
>it's like.  I tried to sell him on Python, but since he couldn't find any
>hold-him-by-the-hand tutorials for complete programming novices, he ended
>up buying a "Discover Programming in C" book and IDE instead.

        The two most common complaints that I see about the available
introductory material are:

        1) Too high-level, assuming that the reader already has
programming experience.  (Someone at IPC6 related their experience
trying to teach Python to a high-school class, and ran into trouble on
this point.)

        2) Too low-level, spending lots of time explaining obvious
things that aren't interesting to experienced programmers.  (I tend to
point such people toward the tutorial.)

        Apparently we need both a K&R-style document, that covers
everything very concisely, and a friendly guide to programming that
starts with explaining what variables and functions are.  Books about
Logo are probably a good model for the introductory text.

        Andrew Kuchling

        http://starship.skyport.net/crew/amk/



Sun, 23 Apr 2000 03:00:00 GMT  
 Python is a mini C?

Quote:

> This is not an urban legend. It appears in one of Microsofts books
> about what a great software process Microsoft has used to build a
> great product like Visual C++ 1.0 . (Please replace "great" with
> "rich" and "cool", as these seem to be the official Microsoft words
> for this stuff).

my $.02: < (sorry, decided to look a little like J or something here):
If we really want to follow a Microsoft style path, I think that after Python
1.5 we should IMMEDIATELY jump to 3.0, forwarded by a jump to 5.0 with less
fanfare (there will be a Python 4.02, but its new shell features will be so
dismally disappointing that everyone will continue to use 3.0 with service
pack 3, unless they wish to install the newest internet "preview release"
features which will REQUIRE them to reinstall from scratch and use service
pack 2, but that's a moot point).  Of course also we'll have to claim over and
over and over again in Python 3.0 that "Acquisition is a bad thing, nobody
will ever want to use it", but it will be an integral feature of 5.0.  So much
so that people who don't use it will be severely punished and possibly hunted
for their skin.  In the end, we'll bet the farm on Python 2004, but will in
fact end up having to support 1.3 forever no matter how much we try to forget it.

--
"Green Tony squeeled and I'm off to Galaxy X"

                     http://www.digicool.com/



Sun, 23 Apr 2000 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. to CS: or not to CS: in F-PC assembler

2. mini review on BYTE mini review on J

3. NO PYTHON: http://cm.bell-labs.com/cm/cs/who/bwk/interps/pap.html

4. mjc4y@brunelleschi.cs.virginia.edu: python object model

5. mjc4y@brunelleschi.cs.virginia.edu: python object model

6. Macromedia Director Python Xtra Mini-HowTo

7. mini-howto: Apache, NT, Python and Bobo

8. Python is a mini C, book bashing, etc.

9. Book recommendations (Re: Python is a mini C?)

10. Python and Mini SQL

11. (mini-)ANN: Document for Python LaTeX setup

12. Python.Org scheduled mini-downtime

 

 
Powered by phpBB® Forum Software