Author |
Message |
Mark Hammon #1 / 25
|
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 |
|
|
Magnus Lyck #2 / 25
|
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 |
|
|
Case Rool #3 / 25
|
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 |
|
|
S. Hoon Yoo #4 / 25
|
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 |
|
|
Konrad Hinse #5 / 25
|
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 |
|
|
Andrew Kuchlin #6 / 25
|
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 |
|
|
Jeffrey P Shel #7 / 25
|
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 |
|
|
Sean Reifschneid #8 / 25
|
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 |
|
|
John Steve #9 / 25
|
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 |
|
|
Mike Mey #10 / 25
|
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 |
|
|
Fredrik Lund #11 / 25
|
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 |
|
|
Paul Presco #12 / 25
|
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 |
|
|
Joseph J. Stro #13 / 25
|
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 |
|
|
Andrew Kuchlin #14 / 25
|
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 |
|
|
Jeffrey P Shel #15 / 25
|
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 |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|