Python Development Environment?
Locked
123
123
Python Development Environment?
 
Administrator
|
Hi Martin. Well, yes, with all the delightful "agile" languages out
there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), we have definitely been giving them a look. Giles got it right in his response referring to Blender: its kinda a natural for combining modeling with great OpenGL based graphics. Python is also doing quite well providing libraries we need such as GIS and "Scientific packages" of various sorts. But to tell the truth, we seldom do a project in one language or system. So for example, in the project we're looking at, we're using ArcGis to be a data cruncher for us, producing good data for us to input to our programs. We'll certainly automate things with a shell like Bash or similar. (Our Windows users generally use Cygwin). Data transformations are generally done in Awk or Perl. If we find ourselves using Java, we can easily make a service that PHP can easily read the data from as we did in a project last year on document collection indexing. I guess my great wish is for a Java-- .. one that provided all the great cross platform graphics and libraries, but without its verbosity. Processing [Beta] is a great example of what can be done to "tame" Java. Groovy possibly will help, and possibly Jython will succeed. -- Owen Owen Densmore http://backspaces.net - http://redfish.com - http://friam.org On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > Hi Owen (and others), > > I don't know if you've done a comparison between Python and Ruby, but > I'd be curious why you chose Python over Ruby. I have little > experience > with Python and none with Ruby, but I know Ruby has closures, which > (in > my mind) should make vector operations easier. > > Best, > Martin > > Owen Densmore wrote: >> We've been looking into using Python in some modeling efforts. One >> question we stumble across is "What's a good Development >> Environment?" >> >> So what are your experiences? Eclipse + PyDev? Eclipse + >> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented >> programming editor? It'd be sweet if it were cross-platform, running >> on Windows, Mac and Linux so we can all share the pain! >> >> One issue is debugging: we'd like a visual debugger with single >> stepping and break points if at all possible. >> >> -- Owen >> >> Owen Densmore >> http://backspaces.net - http://redfish.com - http://friam.org >> >> >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
This snippet from an interview http://www.artima.com/intv/
aboutme.html with Bruce Eckel about Python hit what I am looking for in a language: Bill Venners: In your keynote, you gave ten reasons you love Python. Number ten was reduced clutter. What did you mean by reduced clutter? Bruce Eckel: They say you can hold seven plus or minus two pieces of information in your mind. I can't remember how to open files in Java. I've written chapters on it. I've done it a bunch of times, but it's too many steps. And when I actually analyze it, I realize these are just silly design decisions that they made. Even if they insisted on using the Decorator pattern in java.io, they should have had a convenience constructor for opening files simply. Because we open files all the time, but nobody can remember how. It is too much information to hold in your mind. The other issue is the effect of an interruption. If you are really deep into doing something and you have an interruption, it's quite a number of minutes before you can get back into that deeply focused state. With programming, imagine you're flowing along. You're thinking, "I know this, and I know this, and I know this," and you are putting things together. And then all of a sudden you run into something like, "I have to open a file and read in the lines." All the clutter in the code you have to write to do that in Java can interrupt the flow of your work. Another number that used to be bandied about is that programmers can produce an average of ten working lines of code per day. Say I open up a file and read in all the lines. In Java, I've probably already used up my ten working lines of code for that day. In Python, I can do it in one line. I can say, "for line in file('filename').readlines ():," and then I'm ready to process the lines. And I can remember that one liner off the top of my head, so I can just really flow with that. Python's minimal clutter also helps when I'm reading somebody else's code. I'm not tripping over verbose syntax and idioms. "Oh I see. Opening the file. Reading the lines." I can grok it. It's very similar to the design patterns in that you have a much denser form of communication. Also, because blocks are denoted by indentation in Python, indentation is uniform in Python programs. And indentation is meaningful to us as readers. So because we have consistent code formatting, I can read somebody else's code and I'm not constantly tripping over, "Oh, I see. They're putting their curly braces here or there." I don't have to think about that. On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > Hi Martin. Well, yes, with all the delightful "agile" languages out > there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), > we have definitely been giving them a look. > > Giles got it right in his response referring to Blender: its kinda a > natural for combining modeling with great OpenGL based graphics. > Python is also doing quite well providing libraries we need such as > GIS and "Scientific packages" of various sorts. > > But to tell the truth, we seldom do a project in one language or > system. So for example, in the project we're looking at, we're using > ArcGis to be a data cruncher for us, producing good data for us to > input to our programs. We'll certainly automate things with a shell > like Bash or similar. (Our Windows users generally use Cygwin). > Data transformations are generally done in Awk or Perl. If we find > ourselves using Java, we can easily make a service that PHP can > easily read the data from as we did in a project last year on > document collection indexing. > > I guess my great wish is for a Java-- .. one that provided all the > great cross platform graphics and libraries, but without its > verbosity. Processing [Beta] is a great example of what can be done > to "tame" Java. Groovy possibly will help, and possibly Jython will > succeed. > > -- Owen > > Owen Densmore > http://backspaces.net - http://redfish.com - http://friam.org > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > >> Hi Owen (and others), >> >> I don't know if you've done a comparison between Python and Ruby, but >> I'd be curious why you chose Python over Ruby. I have little >> experience >> with Python and none with Ruby, but I know Ruby has closures, which >> (in >> my mind) should make vector operations easier. >> >> Best, >> Martin >> >> Owen Densmore wrote: >>> We've been looking into using Python in some modeling efforts. One >>> question we stumble across is "What's a good Development >>> Environment?" >>> >>> So what are your experiences? Eclipse + PyDev? Eclipse + >>> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented >>> programming editor? It'd be sweet if it were cross-platform, >>> running >>> on Windows, Mac and Linux so we can all share the pain! >>> >>> One issue is debugging: we'd like a visual debugger with single >>> stepping and break points if at all possible. >>> >>> -- Owen >>> >>> Owen Densmore >>> http://backspaces.net - http://redfish.com - http://friam.org >>> >>> >>> >>> ============================================================ >>> FRIAM Applied Complexity Group listserv >>> Meets Fridays 9a-11:30 at cafe at St. John's College >>> lectures, archives, unsubscribe, maps at http://www.friam.org >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
What Bruce calls "clutter" I call having a tool at the right level of
abstraction for the application. Thus it always astounded me C became so popular for fairly prosaic applications in the 80s and 90s. Typical business applications have no business worrying about their own memory management nor are pointers a reasonable way to impediment logical indirection.... both concepts add code and mental contortions that makes a coder or team vastly less productive. On the other hand, if it's a high performance bit of systems code, or an application that is all about getting maximum throughput per unit of CPU (say the stat routines inside a reporting application) then by all means use C where there as an actual critical benefit of from doing the extra work and mental contortions to use C instead of a higher level abstraction like Java. Thus as per Owen's comments ... most complicated projects ought to use several tools .. .each at approximately the right level of abstraction for the task at hand ... my own toolkit (yes, more than a bit archaic, but I don't do ALL that much coding anymore!): 1. Perl 4.0 to chain saw data files, to do quick and dirty one off analysis of data, and as a more powerful replacement for shell scripting. I have a rule never to write a Perl program longer than 300 lines. I also write it so it looks just like lobotomized C.. no weird ultra terse Wallisms. 2. Visual Basic 6.0 (I just bought and installed Visual Studio 5.0 .... the .net stuff looks quite kool... but haven't jumped in yet) for most "one man projects" of up to 90 man days that require either a decent GUI and/or require decent performance (such as graphics) or have reasonably subtle algorithmic or logic flow beyond what I'd be comfortable squeezing out of Perl and with most stuff you need to do VB for these middling projects no5ttoo verbose but not too terse. Compare for instance adding components into a project in Java versus VB. Also writing components is vastly simpler in VB. VEry important to me VB has one of the most productive debuggers ever and an excellent code-run-code environment. Extremely productive for a good middle range of projects. Even in my dotage I fairly recently won a coding challenge on a project with VB: "you can't possibly do X in two weeks" ... did and got me a free steak dinner! 3. C (NOT c++!) for high performance or systems stuff .... like my spy to control one of the online Poker applications. I'm a slow C prog but when you need the features it's hard to beat. When you don't, definitely pass it by! Anyway, the point is, any discussion of a tool is only really relevant in the context of an application. The wise technologists has a suite of tools appropriate for a range of applications. I've been meaning to learn Python for like 3 years now ... maybe this discussion (especially if a good tight IDE with debugger is identified) will motivate me! =jim rutt At 10:42 AM 3/1/2006, you wrote: >This snippet from an interview http://www.artima.com/intv/ >aboutme.html with Bruce Eckel about Python hit what I am looking for >in a language: > > >Bill Venners: In your keynote, you gave ten reasons you love Python. >Number ten was reduced clutter. What did you mean by reduced clutter? > >Bruce Eckel: They say you can hold seven plus or minus two pieces of >information in your mind. I can't remember how to open files in Java. >I've written chapters on it. I've done it a bunch of times, but it's >too many steps. And when I actually analyze it, I realize these are >just silly design decisions that they made. Even if they insisted on >using the Decorator pattern in java.io, they should have had a >convenience constructor for opening files simply. Because we open >files all the time, but nobody can remember how. It is too much >information to hold in your mind. > >The other issue is the effect of an interruption. If you are really >deep into doing something and you have an interruption, it's quite a >number of minutes before you can get back into that deeply focused >state. With programming, imagine you're flowing along. You're >thinking, "I know this, and I know this, and I know this," and you >are putting things together. And then all of a sudden you run into >something like, "I have to open a file and read in the lines." All >the clutter in the code you have to write to do that in Java can >interrupt the flow of your work. > >Another number that used to be bandied about is that programmers can >produce an average of ten working lines of code per day. Say I open >up a file and read in all the lines. In Java, I've probably already >used up my ten working lines of code for that day. In Python, I can >do it in one line. I can say, "for line in file('filename').readlines >():," and then I'm ready to process the lines. And I can remember >that one liner off the top of my head, so I can just really flow with >that. > >Python's minimal clutter also helps when I'm reading somebody else's >code. I'm not tripping over verbose syntax and idioms. "Oh I see. >Opening the file. Reading the lines." I can grok it. It's very >similar to the design patterns in that you have a much denser form of >communication. Also, because blocks are denoted by indentation in >Python, indentation is uniform in Python programs. And indentation is >meaningful to us as readers. So because we have consistent code >formatting, I can read somebody else's code and I'm not constantly >tripping over, "Oh, I see. They're putting their curly braces here or >there." I don't have to think about that. > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > Hi Martin. Well, yes, with all the delightful "agile" languages out > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), > > we have definitely been giving them a look. > > > > Giles got it right in his response referring to Blender: its kinda a > > natural for combining modeling with great OpenGL based graphics. > > Python is also doing quite well providing libraries we need such as > > GIS and "Scientific packages" of various sorts. > > > > But to tell the truth, we seldom do a project in one language or > > system. So for example, in the project we're looking at, we're using > > ArcGis to be a data cruncher for us, producing good data for us to > > input to our programs. We'll certainly automate things with a shell > > like Bash or similar. (Our Windows users generally use Cygwin). > > Data transformations are generally done in Awk or Perl. If we find > > ourselves using Java, we can easily make a service that PHP can > > easily read the data from as we did in a project last year on > > document collection indexing. > > > > I guess my great wish is for a Java-- .. one that provided all the > > great cross platform graphics and libraries, but without its > > verbosity. Processing [Beta] is a great example of what can be done > > to "tame" Java. Groovy possibly will help, and possibly Jython will > > succeed. > > > > -- Owen > > > > Owen Densmore > > http://backspaces.net - http://redfish.com - http://friam.org > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > >> Hi Owen (and others), > >> > >> I don't know if you've done a comparison between Python and Ruby, but > >> I'd be curious why you chose Python over Ruby. I have little > >> experience > >> with Python and none with Ruby, but I know Ruby has closures, which > >> (in > >> my mind) should make vector operations easier. > >> > >> Best, > >> Martin > >> > >> Owen Densmore wrote: > >>> We've been looking into using Python in some modeling efforts. One > >>> question we stumble across is "What's a good Development > >>> Environment?" > >>> > >>> So what are your experiences? Eclipse + PyDev? Eclipse + > >>> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented > >>> programming editor? It'd be sweet if it were cross-platform, > >>> running > >>> on Windows, Mac and Linux so we can all share the pain! > >>> > >>> One issue is debugging: we'd like a visual debugger with single > >>> stepping and break points if at all possible. > >>> > >>> -- Owen > >>> > >>> Owen Densmore > >>> http://backspaces.net - http://redfish.com - http://friam.org > >>> > >>> > >>> > >>> ============================================================ > >>> FRIAM Applied Complexity Group listserv > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > >>> lectures, archives, unsubscribe, maps at http://www.friam.org > >> > >> ============================================================ > >> FRIAM Applied Complexity Group listserv > >> Meets Fridays 9a-11:30 at cafe at St. John's College > >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at cafe at St. John's College >lectures, archives, unsubscribe, maps at http://www.friam.org =================================== Jim Rutt voice: 505-989-1115 |
Python Development Environment?
|
|
In reply to this post by Douglas Roberts-2
I was really just kidding. I have Smalltalk on one of my machines at
home and I want to do more with it. But it's true that it doesn't get used a lot in the real world, so to speak. I mainly downloaded it out of a perverse desire to learn a language that wouldn't look good on my resume. On 3/1/06, Douglas Roberts <doug at parrot-farm.net> wrote: > I found myself supressing an urge to lash back at the smalltalk suggestion > as well. Smalltalk is interesting from a purely academic perspective. It > is *not* an appropriate language for developing real-world applications. > > --Doug > > > On 2/28/06, Giles Bowkett <gilesb at gmail.com> wrote: > > > > > Oh yeah, and Smalltalk? Please. Smalltalk is like so mainstream. It's > all about CLU and Eiffel. Get with the times, man. > > -- > Giles Goat Boy > > http://gilesmakesmusic.blogspot.com > http://gileswritescode.blogspot.com > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > -- > Doug Roberts, RTI > 505-455-7333 - Office > 505-670-8195 - Cell > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > -- Giles Goat Boy http://gilesmakesmusic.blogspot.com http://gileswritescode.blogspot.com |
Python Development Environment?
|
|
In reply to this post by Jim Rutt
Hi,
You might all be interested in this empirical comparison of programming languages: http://www.cs.drexel.edu/~souter/cs560/w04/assignments/proj4/paper.pdf In particular, Figure 6 shows programming time, with C/C++/Java all being in the same ballpark, and the scripting languages taking much less time. It broadly confirms the rule of thumb that coding things in scripting languages takes roughly 1/2 the time in a high level language like C/C++/Java. They also have graphs for reliability, memory usage, run time, program size, etc. More details: http://photon.physics.ucf.edu/Public/Python/Documentation/languagecomparisons.pdf - Martin Jim Rutt wrote: > What Bruce calls "clutter" I call having a tool at the right level of > abstraction for the application. Thus > it always astounded me C became so popular for fairly prosaic applications > in the 80s and 90s. Typical business applications have no business > worrying about their own memory management nor are pointers a reasonable > way to impediment logical indirection.... both concepts add code and mental > contortions that makes a coder or team vastly less productive. On the > other hand, if it's a high performance bit of systems code, or an > application that is all about getting maximum throughput per unit of CPU > (say the stat routines inside a reporting application) then by all means > use C where there as an actual critical benefit of from doing the extra > work and mental contortions to use C instead of a higher level abstraction > like Java. > > Thus as per Owen's comments ... most complicated projects ought to use > several tools .. .each at approximately the right level of abstraction for > the task at hand ... my own toolkit (yes, more than a bit archaic, but I > don't do ALL that much coding anymore!): > > 1. Perl 4.0 to chain saw data files, to do quick and dirty one off > analysis of data, and as a more powerful replacement for shell > scripting. I have a rule never to write a Perl program longer than 300 > lines. I also write it so it looks just like lobotomized C.. no weird > ultra terse Wallisms. > > 2. Visual Basic 6.0 (I just bought and installed Visual Studio 5.0 > .... the .net stuff looks quite kool... but haven't jumped in yet) for > most "one man projects" of up to 90 man days that require either a decent > GUI and/or require decent performance (such as graphics) or have reasonably > subtle algorithmic or logic flow beyond what I'd be comfortable squeezing > out of Perl and with most stuff you need to do VB for these middling > projects no5ttoo verbose but not too terse. Compare for instance adding > components into a project in Java versus VB. Also writing components is > vastly simpler in VB. VEry important to me VB has one of the most > productive debuggers ever and an excellent code-run-code > environment. Extremely productive for a good middle range of > projects. Even in my dotage I fairly recently won a coding challenge on a > project with VB: "you can't possibly do X in two weeks" ... did and got me > a free steak dinner! > > 3. C (NOT c++!) for high performance or systems stuff .... like my spy to > control one of the online Poker applications. I'm a slow C prog but when > you need the features it's hard to beat. When you don't, definitely pass > it by! > > Anyway, the point is, any discussion of a tool is only really relevant in > the context of an application. The wise technologists has a suite of tools > appropriate for a range of applications. > > I've been meaning to learn Python for like 3 years now ... maybe this > discussion (especially if a good tight IDE with debugger is identified) > will motivate me! > > =jim rutt > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > >>This snippet from an interview http://www.artima.com/intv/ >>aboutme.html with Bruce Eckel about Python hit what I am looking for >>in a language: >> >> >>Bill Venners: In your keynote, you gave ten reasons you love Python. >>Number ten was reduced clutter. What did you mean by reduced clutter? >> >>Bruce Eckel: They say you can hold seven plus or minus two pieces of >>information in your mind. I can't remember how to open files in Java. >>I've written chapters on it. I've done it a bunch of times, but it's >>too many steps. And when I actually analyze it, I realize these are >>just silly design decisions that they made. Even if they insisted on >>using the Decorator pattern in java.io, they should have had a >>convenience constructor for opening files simply. Because we open >>files all the time, but nobody can remember how. It is too much >>information to hold in your mind. >> >>The other issue is the effect of an interruption. If you are really >>deep into doing something and you have an interruption, it's quite a >>number of minutes before you can get back into that deeply focused >>state. With programming, imagine you're flowing along. You're >>thinking, "I know this, and I know this, and I know this," and you >>are putting things together. And then all of a sudden you run into >>something like, "I have to open a file and read in the lines." All >>the clutter in the code you have to write to do that in Java can >>interrupt the flow of your work. >> >>Another number that used to be bandied about is that programmers can >>produce an average of ten working lines of code per day. Say I open >>up a file and read in all the lines. In Java, I've probably already >>used up my ten working lines of code for that day. In Python, I can >>do it in one line. I can say, "for line in file('filename').readlines >>():," and then I'm ready to process the lines. And I can remember >>that one liner off the top of my head, so I can just really flow with >>that. >> >>Python's minimal clutter also helps when I'm reading somebody else's >>code. I'm not tripping over verbose syntax and idioms. "Oh I see. >>Opening the file. Reading the lines." I can grok it. It's very >>similar to the design patterns in that you have a much denser form of >>communication. Also, because blocks are denoted by indentation in >>Python, indentation is uniform in Python programs. And indentation is >>meaningful to us as readers. So because we have consistent code >>formatting, I can read somebody else's code and I'm not constantly >>tripping over, "Oh, I see. They're putting their curly braces here or >>there." I don't have to think about that. >> >> >>On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: >> >> >>>Hi Martin. Well, yes, with all the delightful "agile" languages out >>>there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), >>>we have definitely been giving them a look. >>> >>>Giles got it right in his response referring to Blender: its kinda a >>>natural for combining modeling with great OpenGL based graphics. >>>Python is also doing quite well providing libraries we need such as >>>GIS and "Scientific packages" of various sorts. >>> >>>But to tell the truth, we seldom do a project in one language or >>>system. So for example, in the project we're looking at, we're using >>>ArcGis to be a data cruncher for us, producing good data for us to >>>input to our programs. We'll certainly automate things with a shell >>>like Bash or similar. (Our Windows users generally use Cygwin). >>>Data transformations are generally done in Awk or Perl. If we find >>>ourselves using Java, we can easily make a service that PHP can >>>easily read the data from as we did in a project last year on >>>document collection indexing. >>> >>>I guess my great wish is for a Java-- .. one that provided all the >>>great cross platform graphics and libraries, but without its >>>verbosity. Processing [Beta] is a great example of what can be done >>>to "tame" Java. Groovy possibly will help, and possibly Jython will >>>succeed. >>> >>> -- Owen >>> >>>Owen Densmore >>>http://backspaces.net - http://redfish.com - http://friam.org >>> >>> >>>On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: >>> >>> >>>>Hi Owen (and others), >>>> >>>>I don't know if you've done a comparison between Python and Ruby, but >>>>I'd be curious why you chose Python over Ruby. I have little >>>>experience >>>>with Python and none with Ruby, but I know Ruby has closures, which >>>>(in >>>>my mind) should make vector operations easier. >>>> >>>>Best, >>>>Martin >>>> >>>>Owen Densmore wrote: >>>> >>>>>We've been looking into using Python in some modeling efforts. One >>>>>question we stumble across is "What's a good Development >>>>>Environment?" >>>>> >>>>>So what are your experiences? Eclipse + PyDev? Eclipse + >>>>>TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented >>>>>programming editor? It'd be sweet if it were cross-platform, >>>>>running >>>>>on Windows, Mac and Linux so we can all share the pain! >>>>> >>>>>One issue is debugging: we'd like a visual debugger with single >>>>>stepping and break points if at all possible. >>>>> >>>>> -- Owen >>>>> >>>>>Owen Densmore >>>>>http://backspaces.net - http://redfish.com - http://friam.org >>>>> >>>>> >>>>> >>>>>============================================================ >>>>>FRIAM Applied Complexity Group listserv >>>>>Meets Fridays 9a-11:30 at cafe at St. John's College >>>>>lectures, archives, unsubscribe, maps at http://www.friam.org >>>> >>>>============================================================ >>>>FRIAM Applied Complexity Group listserv >>>>Meets Fridays 9a-11:30 at cafe at St. John's College >>>>lectures, archives, unsubscribe, maps at http://www.friam.org >>> >>> >>>============================================================ >>>FRIAM Applied Complexity Group listserv >>>Meets Fridays 9a-11:30 at cafe at St. John's College >>>lectures, archives, unsubscribe, maps at http://www.friam.org >> >> >>============================================================ >>FRIAM Applied Complexity Group listserv >>Meets Fridays 9a-11:30 at cafe at St. John's College >>lectures, archives, unsubscribe, maps at http://www.friam.org > > > =================================== > Jim Rutt > voice: 505-989-1115 > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
Python Development Environment?
|
|
In reply to this post by Jim Rutt
Disagree with this: the performance differences between C & C++ have all but
gone away. I contend that they are now essentially equivalent when used in HPC. At NCSA in Urbana those codes that are not running fortran <shudder> are running C++/C. --Doug On 3/1/06, Jim Rutt <jim at jimrutt.com> wrote: > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > =jim rutt > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > >This snippet from an interview http://www.artima.com/intv/ > >aboutme.html with Bruce Eckel about Python hit what I am looking for > >in a language: > > > > > >Bill Venners: In your keynote, you gave ten reasons you love Python. > >Number ten was reduced clutter. What did you mean by reduced clutter? > > > >Bruce Eckel: They say you can hold seven plus or minus two pieces of > >information in your mind. I can't remember how to open files in Java. > >I've written chapters on it. I've done it a bunch of times, but it's > >too many steps. And when I actually analyze it, I realize these are > >just silly design decisions that they made. Even if they insisted on > >using the Decorator pattern in java.io, they should have had a > >convenience constructor for opening files simply. Because we open > >files all the time, but nobody can remember how. It is too much > >information to hold in your mind. > > > >The other issue is the effect of an interruption. If you are really > >deep into doing something and you have an interruption, it's quite a > >number of minutes before you can get back into that deeply focused > >state. With programming, imagine you're flowing along. You're > >thinking, "I know this, and I know this, and I know this," and you > >are putting things together. And then all of a sudden you run into > >something like, "I have to open a file and read in the lines." All > >the clutter in the code you have to write to do that in Java can > >interrupt the flow of your work. > > > >Another number that used to be bandied about is that programmers can > >produce an average of ten working lines of code per day. Say I open > >up a file and read in all the lines. In Java, I've probably already > >used up my ten working lines of code for that day. In Python, I can > >do it in one line. I can say, "for line in file('filename').readlines > >():," and then I'm ready to process the lines. And I can remember > >that one liner off the top of my head, so I can just really flow with > >that. > > > >Python's minimal clutter also helps when I'm reading somebody else's > >code. I'm not tripping over verbose syntax and idioms. "Oh I see. > >Opening the file. Reading the lines." I can grok it. It's very > >similar to the design patterns in that you have a much denser form of > >communication. Also, because blocks are denoted by indentation in > >Python, indentation is uniform in Python programs. And indentation is > >meaningful to us as readers. So because we have consistent code > >formatting, I can read somebody else's code and I'm not constantly > >tripping over, "Oh, I see. They're putting their curly braces here or > >there." I don't have to think about that. > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > Hi Martin. Well, yes, with all the delightful "agile" languages out > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), > > > we have definitely been giving them a look. > > > > > > Giles got it right in his response referring to Blender: its kinda a > > > natural for combining modeling with great OpenGL based graphics. > > > Python is also doing quite well providing libraries we need such as > > > GIS and "Scientific packages" of various sorts. > > > > > > But to tell the truth, we seldom do a project in one language or > > > system. So for example, in the project we're looking at, we're using > > > ArcGis to be a data cruncher for us, producing good data for us to > > > input to our programs. We'll certainly automate things with a shell > > > like Bash or similar. (Our Windows users generally use Cygwin). > > > Data transformations are generally done in Awk or Perl. If we find > > > ourselves using Java, we can easily make a service that PHP can > > > easily read the data from as we did in a project last year on > > > document collection indexing. > > > > > > I guess my great wish is for a Java-- .. one that provided all the > > > great cross platform graphics and libraries, but without its > > > verbosity. Processing [Beta] is a great example of what can be done > > > to "tame" Java. Groovy possibly will help, and possibly Jython will > > > succeed. > > > > > > -- Owen > > > > > > Owen Densmore > > > http://backspaces.net - http://redfish.com - http://friam.org > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > >> Hi Owen (and others), > > >> > > >> I don't know if you've done a comparison between Python and Ruby, but > > >> I'd be curious why you chose Python over Ruby. I have little > > >> experience > > >> with Python and none with Ruby, but I know Ruby has closures, which > > >> (in > > >> my mind) should make vector operations easier. > > >> > > >> Best, > > >> Martin > > >> > > >> Owen Densmore wrote: > > >>> We've been looking into using Python in some modeling efforts. One > > >>> question we stumble across is "What's a good Development > > >>> Environment?" > > >>> > > >>> So what are your experiences? Eclipse + PyDev? Eclipse + > > >>> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented > > >>> programming editor? It'd be sweet if it were cross-platform, > > >>> running > > >>> on Windows, Mac and Linux so we can all share the pain! > > >>> > > >>> One issue is debugging: we'd like a visual debugger with single > > >>> stepping and break points if at all possible. > > >>> > > >>> -- Owen > > >>> > > >>> Owen Densmore > > >>> http://backspaces.net - http://redfish.com - http://friam.org > > >>> > > >>> > > >>> > > >>> ============================================================ > > >>> FRIAM Applied Complexity Group listserv > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > >>> lectures, archives, unsubscribe, maps at http://www.friam.org > > >> > > >> ============================================================ > > >> FRIAM Applied Complexity Group listserv > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > >============================================================ > >FRIAM Applied Complexity Group listserv > >Meets Fridays 9a-11:30 at cafe at St. John's College > >lectures, archives, unsubscribe, maps at http://www.friam.org > > =================================== > Jim Rutt > voice: 505-989-1115 > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > -- Doug Roberts, RTI 505-455-7333 - Office 505-670-8195 - Cell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20060301/284b578d/attachment-0001.htm |
Python Development Environment?
|
|
I'm surprised at that. A while ago (5 yrs? 10 yrs?) C++ was generally
the faster language, e.g. with templates for sorting, so you don't need function call overhead for comparison, and with inline functions being more common than macros. What has closed the gap? Has C actually gotten faster? Or C++ slower? Either one seems hard to believe. - Martin Douglas Roberts wrote: > Disagree with this: the performance differences between C & C++ have all > but gone away. I contend that they are now essentially equivalent when > used in HPC. At NCSA in Urbana those codes that are not running fortran > <shudder> are running C++/C. > > --Doug > > On 3/1/06, *Jim Rutt* <jim at jimrutt.com <mailto:jim at jimrutt.com>> wrote: > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > =jim rutt > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > >This snippet from an interview http://www.artima.com/intv/ > >aboutme.html with Bruce Eckel about Python hit what I am looking for > >in a language: > > > > > >Bill Venners: In your keynote, you gave ten reasons you love Python. > >Number ten was reduced clutter. What did you mean by reduced clutter? > > > >Bruce Eckel: They say you can hold seven plus or minus two pieces of > >information in your mind. I can't remember how to open files in Java. > >I've written chapters on it. I've done it a bunch of times, but it's > >too many steps. And when I actually analyze it, I realize these are > >just silly design decisions that they made. Even if they insisted on > >using the Decorator pattern in java.io <http://java.io>, they > should have had a > >convenience constructor for opening files simply. Because we open > >files all the time, but nobody can remember how. It is too much > >information to hold in your mind. > > > >The other issue is the effect of an interruption. If you are really > >deep into doing something and you have an interruption, it's quite a > >number of minutes before you can get back into that deeply focused > >state. With programming, imagine you're flowing along. You're > >thinking, "I know this, and I know this, and I know this," and you > >are putting things together. And then all of a sudden you run into > >something like, "I have to open a file and read in the lines." All > >the clutter in the code you have to write to do that in Java can > >interrupt the flow of your work. > > > >Another number that used to be bandied about is that programmers can > >produce an average of ten working lines of code per day. Say I open > >up a file and read in all the lines. In Java, I've probably already > >used up my ten working lines of code for that day. In Python, I can > >do it in one line. I can say, "for line in file('filename').readlines > >():," and then I'm ready to process the lines. And I can remember > >that one liner off the top of my head, so I can just really flow with > >that. > > > >Python's minimal clutter also helps when I'm reading somebody else's > >code. I'm not tripping over verbose syntax and idioms. "Oh I see. > >Opening the file. Reading the lines." I can grok it. It's very > >similar to the design patterns in that you have a much denser form of > >communication. Also, because blocks are denoted by indentation in > >Python, indentation is uniform in Python programs. And indentation is > >meaningful to us as readers. So because we have consistent code > >formatting, I can read somebody else's code and I'm not constantly > >tripping over, "Oh, I see. They're putting their curly braces here or > >there." I don't have to think about that. > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > Hi Martin. Well, yes, with all the delightful "agile" > languages out > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several > others), > > > we have definitely been giving them a look. > > > > > > Giles got it right in his response referring to Blender: its > kinda a > > > natural for combining modeling with great OpenGL based graphics. > > > Python is also doing quite well providing libraries we need such as > > > GIS and "Scientific packages" of various sorts. > > > > > > But to tell the truth, we seldom do a project in one language or > > > system. So for example, in the project we're looking at, we're > using > > > ArcGis to be a data cruncher for us, producing good data for us to > > > input to our programs. We'll certainly automate things with a > shell > > > like Bash or similar. (Our Windows users generally use Cygwin). > > > Data transformations are generally done in Awk or Perl. If we > find > > > ourselves using Java, we can easily make a service that PHP can > > > easily read the data from as we did in a project last year on > > > document collection indexing. > > > > > > I guess my great wish is for a Java-- .. one that provided all the > > > great cross platform graphics and libraries, but without its > > > verbosity. Processing [Beta] is a great example of what can be > done > > > to "tame" Java. Groovy possibly will help, and possibly Jython > will > > > succeed. > > > > > > -- Owen > > > > > > Owen Densmore > > > http://backspaces.net - http://redfish.com <http://redfish.com> > - http://friam.org > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > >> Hi Owen (and others), > > >> > > >> I don't know if you've done a comparison between Python and > Ruby, but > > >> I'd be curious why you chose Python over Ruby. I have little > > >> experience > > >> with Python and none with Ruby, but I know Ruby has closures, > which > > >> (in > > >> my mind) should make vector operations easier. > > >> > > >> Best, > > >> Martin > > >> > > >> Owen Densmore wrote: > > >>> We've been looking into using Python in some modeling > efforts. One > > >>> question we stumble across is "What's a good Development > > >>> Environment?" > > >>> > > >>> So what are your experiences? Eclipse + PyDev? Eclipse + > > >>> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented > > >>> programming editor? It'd be sweet if it were cross-platform, > > >>> running > > >>> on Windows, Mac and Linux so we can all share the pain! > > >>> > > >>> One issue is debugging: we'd like a visual debugger with single > > >>> stepping and break points if at all possible. > > >>> > > >>> -- Owen > > >>> > > >>> Owen Densmore > > >>> http://backspaces.net - http://redfish.com - http://friam.org > > >>> > > >>> > > >>> > > >>> ============================================================ > > >>> FRIAM Applied Complexity Group listserv > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > >>> lectures, archives, unsubscribe, maps at http://www.friam.org > > >> > > >> ============================================================ > > >> FRIAM Applied Complexity Group listserv > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > >============================================================ > >FRIAM Applied Complexity Group listserv > >Meets Fridays 9a-11:30 at cafe at St. John's College > >lectures, archives, unsubscribe, maps at http://www.friam.org > > =================================== > Jim Rutt > voice: 505-989-1115 > > > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > -- > Doug Roberts, RTI > 505-455-7333 - Office > 505-670-8195 - Cell > > > ------------------------------------------------------------------------ > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
Python Development Environment?
|
|
Actually, I believe it was the other way around: C++ (the newer of the two
languages) was always a bit slower than C. Templates do not eliminate function call overhead; rather, they introduce an additional dereferencing requirement to handle lookups in the vtable. --Doug On 3/1/06, Martin C. Martin <martin at martincmartin.com> wrote: > > I'm surprised at that. A while ago (5 yrs? 10 yrs?) C++ was generally > the faster language, e.g. with templates for sorting, so you don't need > function call overhead for comparison, and with inline functions being > more common than macros. What has closed the gap? Has C actually > gotten faster? Or C++ slower? Either one seems hard to believe. > > - Martin > > Douglas Roberts wrote: > > Disagree with this: the performance differences between C & C++ have all > > but gone away. I contend that they are now essentially equivalent when > > used in HPC. At NCSA in Urbana those codes that are not running fortran > > <shudder> are running C++/C. > > > > --Doug > > > > On 3/1/06, *Jim Rutt* <jim at jimrutt.com <mailto:jim at jimrutt.com>> wrote: > > > > > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > > > > =jim rutt > > > > > > > > > > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > > >This snippet from an interview http://www.artima.com/intv/ > > >aboutme.html with Bruce Eckel about Python hit what I am looking > for > > >in a language: > > > > > > > > >Bill Venners: In your keynote, you gave ten reasons you love > Python. > > >Number ten was reduced clutter. What did you mean by reduced > clutter? > > > > > >Bruce Eckel: They say you can hold seven plus or minus two pieces > of > > >information in your mind. I can't remember how to open files in > Java. > > >I've written chapters on it. I've done it a bunch of times, but > it's > > >too many steps. And when I actually analyze it, I realize these > are > > >just silly design decisions that they made. Even if they insisted > on > > >using the Decorator pattern in java.io <http://java.io>, they > > should have had a > > >convenience constructor for opening files simply. Because we open > > >files all the time, but nobody can remember how. It is too much > > >information to hold in your mind. > > > > > >The other issue is the effect of an interruption. If you are > really > > >deep into doing something and you have an interruption, it's quite > a > > >number of minutes before you can get back into that deeply focused > > >state. With programming, imagine you're flowing along. You're > > >thinking, "I know this, and I know this, and I know this," and you > > >are putting things together. And then all of a sudden you run into > > >something like, "I have to open a file and read in the lines." All > > >the clutter in the code you have to write to do that in Java can > > >interrupt the flow of your work. > > > > > >Another number that used to be bandied about is that programmers > can > > >produce an average of ten working lines of code per day. Say I > open > > >up a file and read in all the lines. In Java, I've probably > already > > >used up my ten working lines of code for that day. In Python, I > can > > >do it in one line. I can say, "for line in > file('filename').readlines > > >():," and then I'm ready to process the lines. And I can remember > > >that one liner off the top of my head, so I can just really flow > with > > >that. > > > > > >Python's minimal clutter also helps when I'm reading somebody > else's > > >code. I'm not tripping over verbose syntax and idioms. "Oh I see. > > >Opening the file. Reading the lines." I can grok it. It's very > > >similar to the design patterns in that you have a much denser form > of > > >communication. Also, because blocks are denoted by indentation in > > >Python, indentation is uniform in Python programs. And indentation > is > > >meaningful to us as readers. So because we have consistent code > > >formatting, I can read somebody else's code and I'm not constantly > > >tripping over, "Oh, I see. They're putting their curly braces here > or > > >there." I don't have to think about that. > > > > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > > > Hi Martin. Well, yes, with all the delightful "agile" > > languages out > > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several > > others), > > > > we have definitely been giving them a look. > > > > > > > > Giles got it right in his response referring to Blender: its > > kinda a > > > > natural for combining modeling with great OpenGL based > graphics. > > > > Python is also doing quite well providing libraries we need > such as > > > > GIS and "Scientific packages" of various sorts. > > > > > > > > But to tell the truth, we seldom do a project in one language > or > > > > system. So for example, in the project we're looking at, we're > > using > > > > ArcGis to be a data cruncher for us, producing good data for us > to > > > > input to our programs. We'll certainly automate things with a > > shell > > > > like Bash or similar. (Our Windows users generally use > Cygwin). > > > > Data transformations are generally done in Awk or Perl. If we > > find > > > > ourselves using Java, we can easily make a service that PHP can > > > > easily read the data from as we did in a project last year on > > > > document collection indexing. > > > > > > > > I guess my great wish is for a Java-- .. one that provided all > the > > > > great cross platform graphics and libraries, but without its > > > > verbosity. Processing [Beta] is a great example of what can be > > done > > > > to "tame" Java. Groovy possibly will help, and possibly Jython > > will > > > > succeed. > > > > > > > > -- Owen > > > > > > > > Owen Densmore > > > > http://backspaces.net - http://redfish.com <http://redfish.com> > > - http://friam.org > > > > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > > > >> Hi Owen (and others), > > > >> > > > >> I don't know if you've done a comparison between Python and > > Ruby, but > > > >> I'd be curious why you chose Python over Ruby. I have little > > > >> experience > > > >> with Python and none with Ruby, but I know Ruby has closures, > > which > > > >> (in > > > >> my mind) should make vector operations easier. > > > >> > > > >> Best, > > > >> Martin > > > >> > > > >> Owen Densmore wrote: > > > >>> We've been looking into using Python in some modeling > > efforts. One > > > >>> question we stumble across is "What's a good Development > > > >>> Environment?" > > > >>> > > > >>> So what are your experiences? Eclipse + PyDev? Eclipse + > > > >>> TruStudio? Boa Constructor? WingWare? Vanilla syntax > oriented > > > >>> programming editor? It'd be sweet if it were cross-platform, > > > >>> running > > > >>> on Windows, Mac and Linux so we can all share the pain! > > > >>> > > > >>> One issue is debugging: we'd like a visual debugger with > single > > > >>> stepping and break points if at all possible. > > > >>> > > > >>> -- Owen > > > >>> > > > >>> Owen Densmore > > > >>> http://backspaces.net - http://redfish.com - http://friam.org > > > >>> > > > >>> > > > >>> > > > >>> ============================================================ > > > >>> FRIAM Applied Complexity Group listserv > > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > > >>> lectures, archives, unsubscribe, maps at http://www.friam.org > > > >> > > > >> ============================================================ > > > >> FRIAM Applied Complexity Group listserv > > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > > >> lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > > > ============================================================ > > > > FRIAM Applied Complexity Group listserv > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > >============================================================ > > >FRIAM Applied Complexity Group listserv > > >Meets Fridays 9a-11:30 at cafe at St. John's College > > >lectures, archives, unsubscribe, maps at http://www.friam.org > > > > =================================== > > Jim Rutt > > voice: 505-989-1115 > > > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > -- > > Doug Roberts, RTI > > 505-455-7333 - Office > > 505-670-8195 - Cell > > > > > > ------------------------------------------------------------------------ > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > -- Doug Roberts, RTI 505-455-7333 - Office 505-670-8195 - Cell -------------- next part -------------- An HTML attachment was scrubbed... URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20060301/b4e7f492/attachment-0001.htm |
|
|
In reply to this post by Martin C. Martin-2
somewhat interesting paper BUT since it's based on a one man project of less than 10 man hours it understates tremendously the downside of the C languages..... he did say, though: "?reveals that C and C++ programs are less reliable than the Java and script programs. These differences, however, depend on just a few defective programs and should thus not be generalized. robustness. Most programs cope with this situation well, but half of the Java programs and four script programs?one written in Tcl and three in" In the "real world" the life cycle costs in debugging, testing, and field fixing tend be considerably higher than for languages with higher level abstractions and less ability to shoot off one's toes. Based on many years of managing software developers I'd put out a swag for relative level of effort for "typical business applications" of full life cycle costs by language: C 1000 c++ 500 java 300 Visual Basic 150 PowerBuilder 75 Perl 30 Of course not all projects fit all tools! And projects away from some invented centroid of typicality would advantage some tools and disadvantage others. I'd also add that some of the differences isn't so much in the language as in cultural inheritances: the C languages and many Java progs seem to bullishly retain low productivity tools like vi and command line debuggers, while "higher level language folks" are more comfortable using modern IDEs with integrated visual debuggers. (ducking the cream pies of vi zealots!). Perl of course an outlier there. =jim At 12:07 PM 3/1/2006, you wrote: >Hi, > >You might all be interested in this empirical comparison of programming >languages: > >http://www.cs.drexel.edu/~souter/cs560/w04/assignments/proj4/paper.pdf > >In particular, Figure 6 shows programming time, with C/C++/Java all >being in the same ballpark, and the scripting languages taking much less >time. It broadly confirms the rule of thumb that coding things in >scripting languages takes roughly 1/2 the time in a high level language >like C/C++/Java. They also have graphs for reliability, memory usage, >run time, program size, etc. > >More details: > >http://photon.physics.ucf.edu/Public/Python/Documentation/languagecomparisons.pdf > >- Martin > > >Jim Rutt wrote: > > What Bruce calls "clutter" I call having a tool at the right level of > > abstraction for the application. Thus > > it always astounded me C became so popular for fairly prosaic applications > > in the 80s and 90s. Typical business applications have no business > > worrying about their own memory management nor are pointers a reasonable > > way to impediment logical indirection.... both concepts add code and > mental > > contortions that makes a coder or team vastly less productive. On the > > other hand, if it's a high performance bit of systems code, or an > > application that is all about getting maximum throughput per unit of CPU > > (say the stat routines inside a reporting application) then by all means > > use C where there as an actual critical benefit of from doing the extra > > work and mental contortions to use C instead of a higher level abstraction > > like Java. > > > > Thus as per Owen's comments ... most complicated projects ought to use > > several tools .. .each at approximately the right level of abstraction for > > the task at hand ... my own toolkit (yes, more than a bit archaic, but I > > don't do ALL that much coding anymore!): > > > > 1. Perl 4.0 to chain saw data files, to do quick and dirty one off > > analysis of data, and as a more powerful replacement for shell > > scripting. I have a rule never to write a Perl program longer than 300 > > lines. I also write it so it looks just like lobotomized C.. no weird > > ultra terse Wallisms. > > > > 2. Visual Basic 6.0 (I just bought and installed Visual Studio 5.0 > > .... the .net stuff looks quite kool... but haven't jumped in yet) for > > most "one man projects" of up to 90 man days that require either a decent > > GUI and/or require decent performance (such as graphics) or have > reasonably > > subtle algorithmic or logic flow beyond what I'd be comfortable squeezing > > out of Perl and with most stuff you need to do VB for these middling > > projects no5ttoo verbose but not too terse. Compare for instance adding > > components into a project in Java versus VB. Also writing components is > > vastly simpler in VB. VEry important to me VB has one of the most > > productive debuggers ever and an excellent code-run-code > > environment. Extremely productive for a good middle range of > > projects. Even in my dotage I fairly recently won a coding challenge > on a > > project with VB: "you can't possibly do X in two weeks" ... did and got me > > a free steak dinner! > > > > 3. C (NOT c++!) for high performance or systems stuff .... like my > spy to > > control one of the online Poker applications. I'm a slow C prog but when > > you need the features it's hard to beat. When you don't, definitely pass > > it by! > > > > Anyway, the point is, any discussion of a tool is only really relevant in > > the context of an application. The wise technologists has a suite of > tools > > appropriate for a range of applications. > > > > I've been meaning to learn Python for like 3 years now ... maybe this > > discussion (especially if a good tight IDE with debugger is identified) > > will motivate me! > > > > =jim rutt > > > > > > > > > > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > > > >>This snippet from an interview http://www.artima.com/intv/ > >>aboutme.html with Bruce Eckel about Python hit what I am looking for > >>in a language: > >> > >> > >>Bill Venners: In your keynote, you gave ten reasons you love Python. > >>Number ten was reduced clutter. What did you mean by reduced clutter? > >> > >>Bruce Eckel: They say you can hold seven plus or minus two pieces of > >>information in your mind. I can't remember how to open files in Java. > >>I've written chapters on it. I've done it a bunch of times, but it's > >>too many steps. And when I actually analyze it, I realize these are > >>just silly design decisions that they made. Even if they insisted on > >>using the Decorator pattern in java.io, they should have had a > >>convenience constructor for opening files simply. Because we open > >>files all the time, but nobody can remember how. It is too much > >>information to hold in your mind. > >> > >>The other issue is the effect of an interruption. If you are really > >>deep into doing something and you have an interruption, it's quite a > >>number of minutes before you can get back into that deeply focused > >>state. With programming, imagine you're flowing along. You're > >>thinking, "I know this, and I know this, and I know this," and you > >>are putting things together. And then all of a sudden you run into > >>something like, "I have to open a file and read in the lines." All > >>the clutter in the code you have to write to do that in Java can > >>interrupt the flow of your work. > >> > >>Another number that used to be bandied about is that programmers can > >>produce an average of ten working lines of code per day. Say I open > >>up a file and read in all the lines. In Java, I've probably already > >>used up my ten working lines of code for that day. In Python, I can > >>do it in one line. I can say, "for line in file('filename').readlines > >>():," and then I'm ready to process the lines. And I can remember > >>that one liner off the top of my head, so I can just really flow with > >>that. > >> > >>Python's minimal clutter also helps when I'm reading somebody else's > >>code. I'm not tripping over verbose syntax and idioms. "Oh I see. > >>Opening the file. Reading the lines." I can grok it. It's very > >>similar to the design patterns in that you have a much denser form of > >>communication. Also, because blocks are denoted by indentation in > >>Python, indentation is uniform in Python programs. And indentation is > >>meaningful to us as readers. So because we have consistent code > >>formatting, I can read somebody else's code and I'm not constantly > >>tripping over, "Oh, I see. They're putting their curly braces here or > >>there." I don't have to think about that. > >> > >> > >>On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > >> > >> > >>>Hi Martin. Well, yes, with all the delightful "agile" languages out > >>>there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), > >>>we have definitely been giving them a look. > >>> > >>>Giles got it right in his response referring to Blender: its kinda a > >>>natural for combining modeling with great OpenGL based graphics. > >>>Python is also doing quite well providing libraries we need such as > >>>GIS and "Scientific packages" of various sorts. > >>> > >>>But to tell the truth, we seldom do a project in one language or > >>>system. So for example, in the project we're looking at, we're using > >>>ArcGis to be a data cruncher for us, producing good data for us to > >>>input to our programs. We'll certainly automate things with a shell > >>>like Bash or similar. (Our Windows users generally use Cygwin). > >>>Data transformations are generally done in Awk or Perl. If we find > >>>ourselves using Java, we can easily make a service that PHP can > >>>easily read the data from as we did in a project last year on > >>>document collection indexing. > >>> > >>>I guess my great wish is for a Java-- .. one that provided all the > >>>great cross platform graphics and libraries, but without its > >>>verbosity. Processing [Beta] is a great example of what can be done > >>>to "tame" Java. Groovy possibly will help, and possibly Jython will > >>>succeed. > >>> > >>> -- Owen > >>> > >>>Owen Densmore > >>>http://backspaces.net - http://redfish.com - http://friam.org > >>> > >>> > >>>On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > >>> > >>> > >>>>Hi Owen (and others), > >>>> > >>>>I don't know if you've done a comparison between Python and Ruby, but > >>>>I'd be curious why you chose Python over Ruby. I have little > >>>>experience > >>>>with Python and none with Ruby, but I know Ruby has closures, which > >>>>(in > >>>>my mind) should make vector operations easier. > >>>> > >>>>Best, > >>>>Martin > >>>> > >>>>Owen Densmore wrote: > >>>> > >>>>>We've been looking into using Python in some modeling efforts. One > >>>>>question we stumble across is "What's a good Development > >>>>>Environment?" > >>>>> > >>>>>So what are your experiences? Eclipse + PyDev? Eclipse + > >>>>>TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented > >>>>>programming editor? It'd be sweet if it were cross-platform, > >>>>>running > >>>>>on Windows, Mac and Linux so we can all share the pain! > >>>>> > >>>>>One issue is debugging: we'd like a visual debugger with single > >>>>>stepping and break points if at all possible. > >>>>> > >>>>> -- Owen > >>>>> > >>>>>Owen Densmore > >>>>>http://backspaces.net - http://redfish.com - http://friam.org > >>>>> > >>>>> > >>>>> > >>>>>============================================================ > >>>>>FRIAM Applied Complexity Group listserv > >>>>>Meets Fridays 9a-11:30 at cafe at St. John's College > >>>>>lectures, archives, unsubscribe, maps at http://www.friam.org > >>>> > >>>>============================================================ > >>>>FRIAM Applied Complexity Group listserv > >>>>Meets Fridays 9a-11:30 at cafe at St. John's College > >>>>lectures, archives, unsubscribe, maps at http://www.friam.org > >>> > >>> > >>>============================================================ > >>>FRIAM Applied Complexity Group listserv > >>>Meets Fridays 9a-11:30 at cafe at St. John's College > >>>lectures, archives, unsubscribe, maps at http://www.friam.org > >> > >> > >>============================================================ > >>FRIAM Applied Complexity Group listserv > >>Meets Fridays 9a-11:30 at cafe at St. John's College > >>lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > =================================== > > Jim Rutt > > voice: 505-989-1115 > > > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at cafe at St. John's College >lectures, archives, unsubscribe, maps at http://www.friam.org =================================== Jim Rutt voice: 505-989-1115 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://redfish.com/pipermail/friam_redfish.com/attachments/20060301/ef07cc89/attachment-0001.htm |
Python Development Environment?
|
|
In reply to this post by Douglas Roberts-2
Douglas Roberts wrote: > Actually, I believe it was the other way around: C++ (the newer of the > two languages) was always a bit slower than C. Well, C's features are a subset of C++'s, so if you use none of the same features, C++ is the same as C. I suppose those new to C++'s features could easily write slow code, but that's true of anyone in any language. If you compare people proficient in both languages, I'd be surprised if the C++ code is slower than the C code. > Templates do not > eliminate function call overhead; rather, they introduce an additional > dereferencing requirement to handle lookups in the vtable. Perhaps you're thinking of virtual functions? If these are used where function pointers used to be used, it does add one extra dereference; but if you're calling a callback, that's generally not noticeable. C's qsort() needs to call a function to compare pairs of elements, whereas std::sort() can inline this operation. That, in fact, was one of the main motivations for templates, as I infer from Stroustroup's writings. Sorting a list of ints, or a list of structs/classes by a single field, is much faster in C++ than C. - Martin > > --Doug > > On 3/1/06, *Martin C. Martin* <martin at martincmartin.com > <mailto:martin at martincmartin.com>> wrote: > > I'm surprised at that. A while ago (5 yrs? 10 yrs?) C++ was generally > the faster language, e.g. with templates for sorting, so you don't need > function call overhead for comparison, and with inline functions being > more common than macros. What has closed the gap? Has C actually > gotten faster? Or C++ slower? Either one seems hard to believe. > > - Martin > > Douglas Roberts wrote: > > Disagree with this: the performance differences between C & C++ > have all > > but gone away. I contend that they are now essentially > equivalent when > > used in HPC. At NCSA in Urbana those codes that are not running > fortran > > <shudder> are running C++/C. > > > > --Doug > > > > On 3/1/06, *Jim Rutt* <jim at jimrutt.com <mailto:jim at jimrutt.com> > <mailto:jim at jimrutt.com <mailto:jim at jimrutt.com>>> wrote: > > > > > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > > > > =jim rutt > > > > > > > > > > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > > >This snippet from an interview http://www.artima.com/intv/ > > >aboutme.html with Bruce Eckel about Python hit what I am > looking for > > >in a language: > > > > > > > > >Bill Venners: In your keynote, you gave ten reasons you > love Python. > > >Number ten was reduced clutter. What did you mean by > reduced clutter? > > > > > >Bruce Eckel: They say you can hold seven plus or minus two > pieces of > > >information in your mind. I can't remember how to open > files in Java. > > >I've written chapters on it. I've done it a bunch of times, > but it's > > >too many steps. And when I actually analyze it, I realize > these are > > >just silly design decisions that they made. Even if they > insisted on > > >using the Decorator pattern in java.io <http://java.io> > <http://java.io>, they > > should have had a > > >convenience constructor for opening files simply. Because > we open > > >files all the time, but nobody can remember how. It is too much > > >information to hold in your mind. > > > > > >The other issue is the effect of an interruption. If you > are really > > >deep into doing something and you have an interruption, > it's quite a > > >number of minutes before you can get back into that deeply > focused > > >state. With programming, imagine you're flowing along. You're > > >thinking, "I know this, and I know this, and I know this," > and you > > >are putting things together. And then all of a sudden you > run into > > >something like, "I have to open a file and read in the > lines." All > > >the clutter in the code you have to write to do that in > Java can > > >interrupt the flow of your work. > > > > > >Another number that used to be bandied about is that > programmers can > > >produce an average of ten working lines of code per day. > Say I open > > >up a file and read in all the lines. In Java, I've probably > already > > >used up my ten working lines of code for that day. In > Python, I can > > >do it in one line. I can say, "for line in > file('filename').readlines > > >():," and then I'm ready to process the lines. And I can > remember > > >that one liner off the top of my head, so I can just really > flow with > > >that. > > > > > >Python's minimal clutter also helps when I'm reading > somebody else's > > >code. I'm not tripping over verbose syntax and idioms. "Oh > I see. > > >Opening the file. Reading the lines." I can grok it. It's very > > >similar to the design patterns in that you have a much > denser form of > > >communication. Also, because blocks are denoted by > indentation in > > >Python, indentation is uniform in Python programs. And > indentation is > > >meaningful to us as readers. So because we have consistent code > > >formatting, I can read somebody else's code and I'm not > constantly > > >tripping over, "Oh, I see. They're putting their curly > braces here or > > >there." I don't have to think about that. > > > > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > > > Hi Martin. Well, yes, with all the delightful "agile" > > languages out > > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several > > others), > > > > we have definitely been giving them a look. > > > > > > > > Giles got it right in his response referring to Blender: its > > kinda a > > > > natural for combining modeling with great OpenGL based > graphics. > > > > Python is also doing quite well providing libraries we > need such as > > > > GIS and "Scientific packages" of various sorts. > > > > > > > > But to tell the truth, we seldom do a project in one > language or > > > > system. So for example, in the project we're looking > at, we're > > using > > > > ArcGis to be a data cruncher for us, producing good data > for us to > > > > input to our programs. We'll certainly automate things > with a > > shell > > > > like Bash or similar. (Our Windows users generally use > Cygwin). > > > > Data transformations are generally done in Awk or > Perl. If we > > find > > > > ourselves using Java, we can easily make a service that > PHP can > > > > easily read the data from as we did in a project last > year on > > > > document collection indexing. > > > > > > > > I guess my great wish is for a Java-- .. one that > provided all the > > > > great cross platform graphics and libraries, but without > its > > > > verbosity. Processing [Beta] is a great example of what > can be > > done > > > > to "tame" Java. Groovy possibly will help, and possibly > Jython > > will > > > > succeed. > > > > > > > > -- Owen > > > > > > > > Owen Densmore > > > > http://backspaces.net <http://backspaces.net> - > http://redfish.com <http://redfish.com> > > - http://friam.org > > > > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > > > >> Hi Owen (and others), > > > >> > > > >> I don't know if you've done a comparison between Python > and > > Ruby, but > > > >> I'd be curious why you chose Python over Ruby. I have > little > > > >> experience > > > >> with Python and none with Ruby, but I know Ruby has > closures, > > which > > > >> (in > > > >> my mind) should make vector operations easier. > > > >> > > > >> Best, > > > >> Martin > > > >> > > > >> Owen Densmore wrote: > > > >>> We've been looking into using Python in some modeling > > efforts. One > > > >>> question we stumble across is "What's a good Development > > > >>> Environment?" > > > >>> > > > >>> So what are your experiences? Eclipse + PyDev? Eclipse + > > > >>> TruStudio? Boa Constructor? WingWare? Vanilla > syntax oriented > > > >>> programming editor? It'd be sweet if it were > cross-platform, > > > >>> running > > > >>> on Windows, Mac and Linux so we can all share the pain! > > > >>> > > > >>> One issue is debugging: we'd like a visual debugger > with single > > > >>> stepping and break points if at all possible. > > > >>> > > > >>> -- Owen > > > >>> > > > >>> Owen Densmore > > > >>> http://backspaces.net - http://redfish.com - > http://friam.org > > > >>> > > > >>> > > > >>> > > > >>> > ============================================================ > > > >>> FRIAM Applied Complexity Group listserv > > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > > >>> lectures, archives, unsubscribe, maps at > http://www.friam.org > > > >> > > > >> > ============================================================ > > > >> FRIAM Applied Complexity Group listserv > > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > > >> lectures, archives, unsubscribe, maps at > http://www.friam.org > > > > > > > > > > > > ============================================================ > > > > FRIAM Applied Complexity Group listserv > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > lectures, archives, unsubscribe, maps at > http://www.friam.org > > > > > > > > >============================================================ > > >FRIAM Applied Complexity Group listserv > > >Meets Fridays 9a-11:30 at cafe at St. John's College > > >lectures, archives, unsubscribe, maps at > http://www.friam.org <http://www.friam.org> > > > > =================================== > > Jim Rutt > > voice: 505-989-1115 > > > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > -- > > Doug Roberts, RTI > > 505-455-7333 - Office > > 505-670-8195 - Cell > > > > > > > ------------------------------------------------------------------------ > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > -- > Doug Roberts, RTI > 505-455-7333 - Office > 505-670-8195 - Cell > > > ------------------------------------------------------------------------ > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
Today of course the state of the art compilers are all pretty much C/C++ so
it isn't the compiler implementations I was refering to... I write my C using the gcc C++ compiler for instance.... it's language features ... if you take advantage of the C++-ish way of design, your code will run slower... perhaps a lot slower as opposed to a traditional C oriented style. =jim At 12:41 PM 3/1/2006, you wrote: >Douglas Roberts wrote: > > Actually, I believe it was the other way around: C++ (the newer of the > > two languages) was always a bit slower than C. > >Well, C's features are a subset of C++'s, so if you use none of the same >features, C++ is the same as C. I suppose those new to C++'s features >could easily write slow code, but that's true of anyone in any language. > If you compare people proficient in both languages, I'd be surprised >if the C++ code is slower than the C code. > > > Templates do not > eliminate function call overhead; rather, they introduce an additional > > dereferencing requirement to handle lookups in the vtable. > >Perhaps you're thinking of virtual functions? If these are used where >function pointers used to be used, it does add one extra dereference; >but if you're calling a callback, that's generally not noticeable. > >C's qsort() needs to call a function to compare pairs of elements, >whereas std::sort() can inline this operation. That, in fact, was one >of the main motivations for templates, as I infer from Stroustroup's >writings. Sorting a list of ints, or a list of structs/classes by a >single field, is much faster in C++ than C. > >- Martin > > > > > --Doug > > > > On 3/1/06, *Martin C. Martin* <martin at martincmartin.com > > <mailto:martin at martincmartin.com>> wrote: > > > > I'm surprised at that. A while ago (5 yrs? 10 yrs?) C++ was generally > > the faster language, e.g. with templates for sorting, so you don't need > > function call overhead for comparison, and with inline functions being > > more common than macros. What has closed the gap? Has C actually > > gotten faster? Or C++ slower? Either one seems hard to believe. > > > > - Martin > > > > Douglas Roberts wrote: > > > Disagree with this: the performance differences between C & C++ > > have all > > > but gone away. I contend that they are now essentially > > equivalent when > > > used in HPC. At NCSA in Urbana those codes that are not running > > fortran > > > <shudder> are running C++/C. > > > > > > --Doug > > > > > > On 3/1/06, *Jim Rutt* <jim at jimrutt.com <mailto:jim at jimrutt.com> > > <mailto:jim at jimrutt.com <mailto:jim at jimrutt.com>>> wrote: > > > > > > > > > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > > > > > > > =jim rutt > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > > > >This snippet from an interview http://www.artima.com/intv/ > > > >aboutme.html with Bruce Eckel about Python hit what I am > > looking for > > > >in a language: > > > > > > > > > > > >Bill Venners: In your keynote, you gave ten reasons you > > love Python. > > > >Number ten was reduced clutter. What did you mean by > > reduced clutter? > > > > > > > >Bruce Eckel: They say you can hold seven plus or minus two > > pieces of > > > >information in your mind. I can't remember how to open > > files in Java. > > > >I've written chapters on it. I've done it a bunch of times, > > but it's > > > >too many steps. And when I actually analyze it, I realize > > these are > > > >just silly design decisions that they made. Even if they > > insisted on > > > >using the Decorator pattern in java.io <http://java.io> > > <http://java.io>, they > > > should have had a > > > >convenience constructor for opening files simply. Because > > we open > > > >files all the time, but nobody can remember how. It is too > much > > > >information to hold in your mind. > > > > > > > >The other issue is the effect of an interruption. If you > > are really > > > >deep into doing something and you have an interruption, > > it's quite a > > > >number of minutes before you can get back into that deeply > > focused > > > >state. With programming, imagine you're flowing along. You're > > > >thinking, "I know this, and I know this, and I know this," > > and you > > > >are putting things together. And then all of a sudden you > > run into > > > >something like, "I have to open a file and read in the > > lines." All > > > >the clutter in the code you have to write to do that in > > Java can > > > >interrupt the flow of your work. > > > > > > > >Another number that used to be bandied about is that > > programmers can > > > >produce an average of ten working lines of code per day. > > Say I open > > > >up a file and read in all the lines. In Java, I've probably > > already > > > >used up my ten working lines of code for that day. In > > Python, I can > > > >do it in one line. I can say, "for line in > > file('filename').readlines > > > >():," and then I'm ready to process the lines. And I can > > remember > > > >that one liner off the top of my head, so I can just really > > flow with > > > >that. > > > > > > > >Python's minimal clutter also helps when I'm reading > > somebody else's > > > >code. I'm not tripping over verbose syntax and idioms. "Oh > > I see. > > > >Opening the file. Reading the lines." I can grok it. It's very > > > >similar to the design patterns in that you have a much > > denser form of > > > >communication. Also, because blocks are denoted by > > indentation in > > > >Python, indentation is uniform in Python programs. And > > indentation is > > > >meaningful to us as readers. So because we have consistent > code > > > >formatting, I can read somebody else's code and I'm not > > constantly > > > >tripping over, "Oh, I see. They're putting their curly > > braces here or > > > >there." I don't have to think about that. > > > > > > > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > > > > > Hi Martin. Well, yes, with all the delightful "agile" > > > languages out > > > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and several > > > others), > > > > > we have definitely been giving them a look. > > > > > > > > > > Giles got it right in his response referring to > Blender: its > > > kinda a > > > > > natural for combining modeling with great OpenGL based > > graphics. > > > > > Python is also doing quite well providing libraries we > > need such as > > > > > GIS and "Scientific packages" of various sorts. > > > > > > > > > > But to tell the truth, we seldom do a project in one > > language or > > > > > system. So for example, in the project we're looking > > at, we're > > > using > > > > > ArcGis to be a data cruncher for us, producing good data > > for us to > > > > > input to our programs. We'll certainly automate things > > with a > > > shell > > > > > like Bash or similar. (Our Windows users generally use > > Cygwin). > > > > > Data transformations are generally done in Awk or > > Perl. If we > > > find > > > > > ourselves using Java, we can easily make a service that > > PHP can > > > > > easily read the data from as we did in a project last > > year on > > > > > document collection indexing. > > > > > > > > > > I guess my great wish is for a Java-- .. one that > > provided all the > > > > > great cross platform graphics and libraries, but without > > its > > > > > verbosity. Processing [Beta] is a great example of what > > can be > > > done > > > > > to "tame" Java. Groovy possibly will help, and possibly > > Jython > > > will > > > > > succeed. > > > > > > > > > > -- Owen > > > > > > > > > > Owen Densmore > > > > > http://backspaces.net <http://backspaces.net> - > > http://redfish.com <http://redfish.com> > > > - http://friam.org > > > > > > > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > > > > > >> Hi Owen (and others), > > > > >> > > > > >> I don't know if you've done a comparison between Python > > and > > > Ruby, but > > > > >> I'd be curious why you chose Python over Ruby. I have > > little > > > > >> experience > > > > >> with Python and none with Ruby, but I know Ruby has > > closures, > > > which > > > > >> (in > > > > >> my mind) should make vector operations easier. > > > > >> > > > > >> Best, > > > > >> Martin > > > > >> > > > > >> Owen Densmore wrote: > > > > >>> We've been looking into using Python in some modeling > > > efforts. One > > > > >>> question we stumble across is "What's a good Development > > > > >>> Environment?" > > > > >>> > > > > >>> So what are your experiences? Eclipse + > PyDev? Eclipse + > > > > >>> TruStudio? Boa Constructor? WingWare? Vanilla > > syntax oriented > > > > >>> programming editor? It'd be sweet if it were > > cross-platform, > > > > >>> running > > > > >>> on Windows, Mac and Linux so we can all share the pain! > > > > >>> > > > > >>> One issue is debugging: we'd like a visual debugger > > with single > > > > >>> stepping and break points if at all possible. > > > > >>> > > > > >>> -- Owen > > > > >>> > > > > >>> Owen Densmore > > > > >>> http://backspaces.net - http://redfish.com - > > http://friam.org > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > ============================================================ > > > > >>> FRIAM Applied Complexity Group listserv > > > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > > > >>> lectures, archives, unsubscribe, maps at > > http://www.friam.org > > > > >> > > > > >> > > ============================================================ > > > > >> FRIAM Applied Complexity Group listserv > > > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > > > >> lectures, archives, unsubscribe, maps at > > http://www.friam.org > > > > > > > > > > > > > > > > ============================================================ > > > > > FRIAM Applied Complexity Group listserv > > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > > lectures, archives, unsubscribe, maps at > > http://www.friam.org > > > > > > > > > > > >============================================================ > > > >FRIAM Applied Complexity Group listserv > > > >Meets Fridays 9a-11:30 at cafe at St. John's College > > > >lectures, archives, unsubscribe, maps at > > http://www.friam.org <http://www.friam.org> > > > > > > =================================== > > > Jim Rutt > > > voice: 505-989-1115 > > > > > > > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > > > > > > -- > > > Doug Roberts, RTI > > > 505-455-7333 - Office > > > 505-670-8195 - Cell > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > -- > > Doug Roberts, RTI > > 505-455-7333 - Office > > 505-670-8195 - Cell > > > > > > ------------------------------------------------------------------------ > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at cafe at St. John's College >lectures, archives, unsubscribe, maps at http://www.friam.org =================================== Jim Rutt voice: 505-989-1115 |
|
|
oddly something stripped off the plusplus's from c-plus-plus in the
previous email..... At 01:09 PM 3/1/2006, you wrote: >Today of course the state of the art compilers are all pretty much C/C++ so >it isn't the compiler implementations I was refering to... I write my C >using the gcc C++ compiler for instance.... it's language features ... if >you take advantage of the C++-ish way of design, your code will run >slower... perhaps a lot slower as opposed to a traditional C oriented style. > >=jim > >At 12:41 PM 3/1/2006, you wrote: > > > >Douglas Roberts wrote: > > > Actually, I believe it was the other way around: C++ (the newer of the > > > two languages) was always a bit slower than C. > > > >Well, C's features are a subset of C++'s, so if you use none of the same > >features, C++ is the same as C. I suppose those new to C++'s features > >could easily write slow code, but that's true of anyone in any language. > > If you compare people proficient in both languages, I'd be surprised > >if the C++ code is slower than the C code. > > > > > Templates do not > > eliminate function call overhead; rather, they introduce an additional > > > dereferencing requirement to handle lookups in the vtable. > > > >Perhaps you're thinking of virtual functions? If these are used where > >function pointers used to be used, it does add one extra dereference; > >but if you're calling a callback, that's generally not noticeable. > > > >C's qsort() needs to call a function to compare pairs of elements, > >whereas std::sort() can inline this operation. That, in fact, was one > >of the main motivations for templates, as I infer from Stroustroup's > >writings. Sorting a list of ints, or a list of structs/classes by a > >single field, is much faster in C++ than C. > > > >- Martin > > > > > > > > --Doug > > > > > > On 3/1/06, *Martin C. Martin* <martin at martincmartin.com > > > <mailto:martin at martincmartin.com>> wrote: > > > > > > I'm surprised at that. A while ago (5 yrs? 10 yrs?) C++ was > generally > > > the faster language, e.g. with templates for sorting, so you > don't need > > > function call overhead for comparison, and with inline functions > being > > > more common than macros. What has closed the gap? Has C actually > > > gotten faster? Or C++ slower? Either one seems hard to believe. > > > > > > - Martin > > > > > > Douglas Roberts wrote: > > > > Disagree with this: the performance differences between C & C++ > > > have all > > > > but gone away. I contend that they are now essentially > > > equivalent when > > > > used in HPC. At NCSA in Urbana those codes that are not running > > > fortran > > > > <shudder> are running C++/C. > > > > > > > > --Doug > > > > > > > > On 3/1/06, *Jim Rutt* <jim at jimrutt.com <mailto:jim at jimrutt.com> > > > <mailto:jim at jimrutt.com <mailto:jim at jimrutt.com>>> wrote: > > > > > > > > > > > > > > > > 3. C (NOT c++!) for high performance or systems stuff .... l > > > > > > > > > > > > =jim rutt > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 10:42 AM 3/1/2006, you wrote: > > > > >This snippet from an interview http://www.artima.com/intv/ > > > > >aboutme.html with Bruce Eckel about Python hit what I am > > > looking for > > > > >in a language: > > > > > > > > > > > > > > >Bill Venners: In your keynote, you gave ten reasons you > > > love Python. > > > > >Number ten was reduced clutter. What did you mean by > > > reduced clutter? > > > > > > > > > >Bruce Eckel: They say you can hold seven plus or minus two > > > pieces of > > > > >information in your mind. I can't remember how to open > > > files in Java. > > > > >I've written chapters on it. I've done it a bunch of times, > > > but it's > > > > >too many steps. And when I actually analyze it, I realize > > > these are > > > > >just silly design decisions that they made. Even if they > > > insisted on > > > > >using the Decorator pattern in java.io <http://java.io> > > > <http://java.io>, they > > > > should have had a > > > > >convenience constructor for opening files simply. Because > > > we open > > > > >files all the time, but nobody can remember how. It is too > > much > > > > >information to hold in your mind. > > > > > > > > > >The other issue is the effect of an interruption. If you > > > are really > > > > >deep into doing something and you have an interruption, > > > it's quite a > > > > >number of minutes before you can get back into that deeply > > > focused > > > > >state. With programming, imagine you're flowing along. > You're > > > > >thinking, "I know this, and I know this, and I know this," > > > and you > > > > >are putting things together. And then all of a sudden you > > > run into > > > > >something like, "I have to open a file and read in the > > > lines." All > > > > >the clutter in the code you have to write to do that in > > > Java can > > > > >interrupt the flow of your work. > > > > > > > > > >Another number that used to be bandied about is that > > > programmers can > > > > >produce an average of ten working lines of code per day. > > > Say I open > > > > >up a file and read in all the lines. In Java, I've probably > > > already > > > > >used up my ten working lines of code for that day. In > > > Python, I can > > > > >do it in one line. I can say, "for line in > > > file('filename').readlines > > > > >():," and then I'm ready to process the lines. And I can > > > remember > > > > >that one liner off the top of my head, so I can just really > > > flow with > > > > >that. > > > > > > > > > >Python's minimal clutter also helps when I'm reading > > > somebody else's > > > > >code. I'm not tripping over verbose syntax and idioms. "Oh > > > I see. > > > > >Opening the file. Reading the lines." I can grok it. > It's very > > > > >similar to the design patterns in that you have a much > > > denser form of > > > > >communication. Also, because blocks are denoted by > > > indentation in > > > > >Python, indentation is uniform in Python programs. And > > > indentation is > > > > >meaningful to us as readers. So because we have consistent > > code > > > > >formatting, I can read somebody else's code and I'm not > > > constantly > > > > >tripping over, "Oh, I see. They're putting their curly > > > braces here or > > > > >there." I don't have to think about that. > > > > > > > > > > > > > > >On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: > > > > > > > > > > > Hi Martin. Well, yes, with all the delightful "agile" > > > > languages out > > > > > > there (Groovy, Ruby, Smalltalk, Python, Jython, and > several > > > > others), > > > > > > we have definitely been giving them a look. > > > > > > > > > > > > Giles got it right in his response referring to > > Blender: its > > > > kinda a > > > > > > natural for combining modeling with great OpenGL based > > > graphics. > > > > > > Python is also doing quite well providing libraries we > > > need such as > > > > > > GIS and "Scientific packages" of various sorts. > > > > > > > > > > > > But to tell the truth, we seldom do a project in one > > > language or > > > > > > system. So for example, in the project we're looking > > > at, we're > > > > using > > > > > > ArcGis to be a data cruncher for us, producing good data > > > for us to > > > > > > input to our programs. We'll certainly automate things > > > with a > > > > shell > > > > > > like Bash or similar. (Our Windows users generally use > > > Cygwin). > > > > > > Data transformations are generally done in Awk or > > > Perl. If we > > > > find > > > > > > ourselves using Java, we can easily make a service that > > > PHP can > > > > > > easily read the data from as we did in a project last > > > year on > > > > > > document collection indexing. > > > > > > > > > > > > I guess my great wish is for a Java-- .. one that > > > provided all the > > > > > > great cross platform graphics and libraries, but without > > > its > > > > > > verbosity. Processing [Beta] is a great example of what > > > can be > > > > done > > > > > > to "tame" Java. Groovy possibly will help, and possibly > > > Jython > > > > will > > > > > > succeed. > > > > > > > > > > > > -- Owen > > > > > > > > > > > > Owen Densmore > > > > > > http://backspaces.net <http://backspaces.net> - > > > http://redfish.com <http://redfish.com> > > > > - http://friam.org > > > > > > > > > > > > > > > > > > On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: > > > > > > > > > > > >> Hi Owen (and others), > > > > > >> > > > > > >> I don't know if you've done a comparison between Python > > > and > > > > Ruby, but > > > > > >> I'd be curious why you chose Python over Ruby. I have > > > little > > > > > >> experience > > > > > >> with Python and none with Ruby, but I know Ruby has > > > closures, > > > > which > > > > > >> (in > > > > > >> my mind) should make vector operations easier. > > > > > >> > > > > > >> Best, > > > > > >> Martin > > > > > >> > > > > > >> Owen Densmore wrote: > > > > > >>> We've been looking into using Python in some modeling > > > > efforts. One > > > > > >>> question we stumble across is "What's a good > Development > > > > > >>> Environment?" > > > > > >>> > > > > > >>> So what are your experiences? Eclipse + > > PyDev? Eclipse + > > > > > >>> TruStudio? Boa Constructor? WingWare? Vanilla > > > syntax oriented > > > > > >>> programming editor? It'd be sweet if it were > > > cross-platform, > > > > > >>> running > > > > > >>> on Windows, Mac and Linux so we can all share the pain! > > > > > >>> > > > > > >>> One issue is debugging: we'd like a visual debugger > > > with single > > > > > >>> stepping and break points if at all possible. > > > > > >>> > > > > > >>> -- Owen > > > > > >>> > > > > > >>> Owen Densmore > > > > > >>> http://backspaces.net - http://redfish.com - > > > http://friam.org > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > ============================================================ > > > > > >>> FRIAM Applied Complexity Group listserv > > > > > >>> Meets Fridays 9a-11:30 at cafe at St. John's College > > > > > >>> lectures, archives, unsubscribe, maps at > > > http://www.friam.org > > > > > >> > > > > > >> > > > ============================================================ > > > > > >> FRIAM Applied Complexity Group listserv > > > > > >> Meets Fridays 9a-11:30 at cafe at St. John's College > > > > > >> lectures, archives, unsubscribe, maps at > > > http://www.friam.org > > > > > > > > > > > > > > > > > > > > ============================================================ > > > > > > FRIAM Applied Complexity Group listserv > > > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > > > lectures, archives, unsubscribe, maps at > > > http://www.friam.org > > > > > > > > > > > > > > >============================================================ > > > > >FRIAM Applied Complexity Group listserv > > > > >Meets Fridays 9a-11:30 at cafe at St. John's College > > > > >lectures, archives, unsubscribe, maps at > > > http://www.friam.org <http://www.friam.org> > > > > > > > > =================================== > > > > Jim Rutt > > > > voice: 505-989-1115 > > > > > > > > > > > > > > > > ============================================================ > > > > FRIAM Applied Complexity Group listserv > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > > > > > > > > > > > -- > > > > Doug Roberts, RTI > > > > 505-455-7333 - Office > > > > 505-670-8195 - Cell > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > ============================================================ > > > > FRIAM Applied Complexity Group listserv > > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > > > > > > > > > > > > -- > > > Doug Roberts, RTI > > > 505-455-7333 - Office > > > 505-670-8195 - Cell > > > > > > > > > ------------------------------------------------------------------------ > > > > > > ============================================================ > > > FRIAM Applied Complexity Group listserv > > > Meets Fridays 9a-11:30 at cafe at St. John's College > > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > >============================================================ > >FRIAM Applied Complexity Group listserv > >Meets Fridays 9a-11:30 at cafe at St. John's College > >lectures, archives, unsubscribe, maps at http://www.friam.org > >=================================== >Jim Rutt >voice: 505-989-1115 > > > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at cafe at St. John's College >lectures, archives, unsubscribe, maps at http://www.friam.org =================================== Jim Rutt voice: 505-989-1115 |
Python Development Environment?
|
Administrator
|
In reply to this post by Joshua Thorp
Josh: Lets suppose, by some miracle, the Groovy folks actually settle
down and build a system that is mature and usable. For folks who haven't seen it: http://groovy.codehaus.org/ Its very Ruby/Python-like and lets you access all of Java. Would it then satisfy Bruce and others like yourself wanting an nimble, agile language? (From what I can tell, its performance is roughly the same as Ruby/Python.) Or are there other features of the Python language/world/community that are more important? -- Owen Owen Densmore http://backspaces.net - http://redfish.com - http://friam.org On Mar 1, 2006, at 10:42 AM, Joshua Thorp wrote: > This snippet from an interview http://www.artima.com/intv/ > aboutme.html with Bruce Eckel about Python hit what I am looking for > in a language: > > Bill Venners: In your keynote, you gave ten reasons you love Python. > Number ten was reduced clutter. What did you mean by reduced clutter? > > Bruce Eckel: They say you can hold seven plus or minus two pieces of > information in your mind. I can't remember how to open files in Java. > I've written chapters on it. I've done it a bunch of times, but it's > too many steps. And when I actually analyze it, I realize these are > just silly design decisions that they made. Even if they insisted on > using the Decorator pattern in java.io, they should have had a > convenience constructor for opening files simply. Because we open > files all the time, but nobody can remember how. It is too much > information to hold in your mind. ... snip ... |
Python Development Environment?
|
|
In reply to this post by Jim Rutt
I definitely disagree with this. The inlining feature of C++
eliminates any performance disadvantage to OO programming. Where C++ rocks over using standard C is the ability to rip and replace data structures - often at algorithm design time, the right choice of data structure is not obvious. With C, you would have to recode to test a different data structure, which is typically not done. The other place C++ rocks over C is the ability to manage heap data by means of stack-based "manager" objects. This saves so much debugging time - about the only time I get a memory leak in a C++ code is if I need to call out to a C library that doesn't do its own memory management. I have a number of times started coding in C, but then always switched to C++ sooner or later. Now I just start in C++ - what's the point. If ANSI C is genuinely a requirement, I back port the code to C (once correctly debugged) as an additional step. C++ does lead increased amounts of object code (due to all the inlining!) This is rarely a problem, except in embedded applications. (I recently needed to fit an application onto a floppy disk, and guess what - I did it in C) Cheers On Wed, Mar 01, 2006 at 01:09:40PM -0700, Jim Rutt wrote: > Today of course the state of the art compilers are all pretty much C/C++ so > it isn't the compiler implementations I was refering to... I write my C > using the gcc C++ compiler for instance.... it's language features ... if > you take advantage of the C++-ish way of design, your code will run > slower... perhaps a lot slower as opposed to a traditional C oriented style. > > =jim > -- *PS: A number of people ask me about the attachment to my email, which is of type "application/pgp-signature". Don't worry, it is not a virus. It is an electronic signature, that may be used to verify this email came from me if you have PGP or GPG installed. Otherwise, you may safely ignore this attachment. ---------------------------------------------------------------------------- A/Prof Russell Standish Phone 8308 3119 (mobile) Mathematics 0425 253119 (") UNSW SYDNEY 2052 R.Standish at unsw.edu.au Australia http://parallel.hpc.unsw.edu.au/rks International prefix +612, Interstate prefix 02 ---------------------------------------------------------------------------- |
Python Development Environment?
|
|
In reply to this post by Martin C. Martin-2
Hmmm. Any more recent comparisons? JDK 1.2.2 is a few years old and
probably not representative of the current state of Java. I'd like to see a comparison using (say) JDK 5.0 and a more recent Python. Carl Martin C. Martin wrote: > Hi, > > You might all be interested in this empirical comparison of programming > languages: > > http://www.cs.drexel.edu/~souter/cs560/w04/assignments/proj4/paper.pdf > > In particular, Figure 6 shows programming time, with C/C++/Java all > being in the same ballpark, and the scripting languages taking much less > time. It broadly confirms the rule of thumb that coding things in > scripting languages takes roughly 1/2 the time in a high level language > like C/C++/Java. They also have graphs for reliability, memory usage, > run time, program size, etc. > > More details: > > http://photon.physics.ucf.edu/Public/Python/Documentation/languagecomparisons.pdf > > - Martin > > > Jim Rutt wrote: > >> What Bruce calls "clutter" I call having a tool at the right level of >> abstraction for the application. Thus >> it always astounded me C became so popular for fairly prosaic applications >> in the 80s and 90s. Typical business applications have no business >> worrying about their own memory management nor are pointers a reasonable >> way to impediment logical indirection.... both concepts add code and mental >> contortions that makes a coder or team vastly less productive. On the >> other hand, if it's a high performance bit of systems code, or an >> application that is all about getting maximum throughput per unit of CPU >> (say the stat routines inside a reporting application) then by all means >> use C where there as an actual critical benefit of from doing the extra >> work and mental contortions to use C instead of a higher level abstraction >> like Java. >> >> Thus as per Owen's comments ... most complicated projects ought to use >> several tools .. .each at approximately the right level of abstraction for >> the task at hand ... my own toolkit (yes, more than a bit archaic, but I >> don't do ALL that much coding anymore!): >> >> 1. Perl 4.0 to chain saw data files, to do quick and dirty one off >> analysis of data, and as a more powerful replacement for shell >> scripting. I have a rule never to write a Perl program longer than 300 >> lines. I also write it so it looks just like lobotomized C.. no weird >> ultra terse Wallisms. >> >> 2. Visual Basic 6.0 (I just bought and installed Visual Studio 5.0 >> .... the .net stuff looks quite kool... but haven't jumped in yet) for >> most "one man projects" of up to 90 man days that require either a decent >> GUI and/or require decent performance (such as graphics) or have reasonably >> subtle algorithmic or logic flow beyond what I'd be comfortable squeezing >> out of Perl and with most stuff you need to do VB for these middling >> projects no5ttoo verbose but not too terse. Compare for instance adding >> components into a project in Java versus VB. Also writing components is >> vastly simpler in VB. VEry important to me VB has one of the most >> productive debuggers ever and an excellent code-run-code >> environment. Extremely productive for a good middle range of >> projects. Even in my dotage I fairly recently won a coding challenge on a >> project with VB: "you can't possibly do X in two weeks" ... did and got me >> a free steak dinner! >> >> 3. C (NOT c++!) for high performance or systems stuff .... like my spy to >> control one of the online Poker applications. I'm a slow C prog but when >> you need the features it's hard to beat. When you don't, definitely pass >> it by! >> >> Anyway, the point is, any discussion of a tool is only really relevant in >> the context of an application. The wise technologists has a suite of tools >> appropriate for a range of applications. >> >> I've been meaning to learn Python for like 3 years now ... maybe this >> discussion (especially if a good tight IDE with debugger is identified) >> will motivate me! >> >> =jim rutt >> >> >> >> >> >> >> >> >> At 10:42 AM 3/1/2006, you wrote: >> >> >>> This snippet from an interview http://www.artima.com/intv/ >>> aboutme.html with Bruce Eckel about Python hit what I am looking for >>> in a language: >>> >>> >>> Bill Venners: In your keynote, you gave ten reasons you love Python. >>> Number ten was reduced clutter. What did you mean by reduced clutter? >>> >>> Bruce Eckel: They say you can hold seven plus or minus two pieces of >>> information in your mind. I can't remember how to open files in Java. >>> I've written chapters on it. I've done it a bunch of times, but it's >>> too many steps. And when I actually analyze it, I realize these are >>> just silly design decisions that they made. Even if they insisted on >>> using the Decorator pattern in java.io, they should have had a >>> convenience constructor for opening files simply. Because we open >>> files all the time, but nobody can remember how. It is too much >>> information to hold in your mind. >>> >>> The other issue is the effect of an interruption. If you are really >>> deep into doing something and you have an interruption, it's quite a >>> number of minutes before you can get back into that deeply focused >>> state. With programming, imagine you're flowing along. You're >>> thinking, "I know this, and I know this, and I know this," and you >>> are putting things together. And then all of a sudden you run into >>> something like, "I have to open a file and read in the lines." All >>> the clutter in the code you have to write to do that in Java can >>> interrupt the flow of your work. >>> >>> Another number that used to be bandied about is that programmers can >>> produce an average of ten working lines of code per day. Say I open >>> up a file and read in all the lines. In Java, I've probably already >>> used up my ten working lines of code for that day. In Python, I can >>> do it in one line. I can say, "for line in file('filename').readlines >>> ():," and then I'm ready to process the lines. And I can remember >>> that one liner off the top of my head, so I can just really flow with >>> that. >>> >>> Python's minimal clutter also helps when I'm reading somebody else's >>> code. I'm not tripping over verbose syntax and idioms. "Oh I see. >>> Opening the file. Reading the lines." I can grok it. It's very >>> similar to the design patterns in that you have a much denser form of >>> communication. Also, because blocks are denoted by indentation in >>> Python, indentation is uniform in Python programs. And indentation is >>> meaningful to us as readers. So because we have consistent code >>> formatting, I can read somebody else's code and I'm not constantly >>> tripping over, "Oh, I see. They're putting their curly braces here or >>> there." I don't have to think about that. >>> >>> >>> On Mar 1, 2006, at 10:16 AM, Owen Densmore wrote: >>> >>> >>> >>>> Hi Martin. Well, yes, with all the delightful "agile" languages out >>>> there (Groovy, Ruby, Smalltalk, Python, Jython, and several others), >>>> we have definitely been giving them a look. >>>> >>>> Giles got it right in his response referring to Blender: its kinda a >>>> natural for combining modeling with great OpenGL based graphics. >>>> Python is also doing quite well providing libraries we need such as >>>> GIS and "Scientific packages" of various sorts. >>>> >>>> But to tell the truth, we seldom do a project in one language or >>>> system. So for example, in the project we're looking at, we're using >>>> ArcGis to be a data cruncher for us, producing good data for us to >>>> input to our programs. We'll certainly automate things with a shell >>>> like Bash or similar. (Our Windows users generally use Cygwin). >>>> Data transformations are generally done in Awk or Perl. If we find >>>> ourselves using Java, we can easily make a service that PHP can >>>> easily read the data from as we did in a project last year on >>>> document collection indexing. >>>> >>>> I guess my great wish is for a Java-- .. one that provided all the >>>> great cross platform graphics and libraries, but without its >>>> verbosity. Processing [Beta] is a great example of what can be done >>>> to "tame" Java. Groovy possibly will help, and possibly Jython will >>>> succeed. >>>> >>>> -- Owen >>>> >>>> Owen Densmore >>>> http://backspaces.net - http://redfish.com - http://friam.org >>>> >>>> >>>> On Feb 28, 2006, at 10:04 AM, Martin C. Martin wrote: >>>> >>>> >>>> >>>>> Hi Owen (and others), >>>>> >>>>> I don't know if you've done a comparison between Python and Ruby, but >>>>> I'd be curious why you chose Python over Ruby. I have little >>>>> experience >>>>> with Python and none with Ruby, but I know Ruby has closures, which >>>>> (in >>>>> my mind) should make vector operations easier. >>>>> >>>>> Best, >>>>> Martin >>>>> >>>>> Owen Densmore wrote: >>>>> >>>>> >>>>>> We've been looking into using Python in some modeling efforts. One >>>>>> question we stumble across is "What's a good Development >>>>>> Environment?" >>>>>> >>>>>> So what are your experiences? Eclipse + PyDev? Eclipse + >>>>>> TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented >>>>>> programming editor? It'd be sweet if it were cross-platform, >>>>>> running >>>>>> on Windows, Mac and Linux so we can all share the pain! >>>>>> >>>>>> One issue is debugging: we'd like a visual debugger with single >>>>>> stepping and break points if at all possible. >>>>>> >>>>>> -- Owen >>>>>> >>>>>> Owen Densmore >>>>>> http://backspaces.net - http://redfish.com - http://friam.org >>>>>> >>>>>> >>>>>> >>>>>> ============================================================ >>>>>> FRIAM Applied Complexity Group listserv >>>>>> Meets Fridays 9a-11:30 at cafe at St. John's College >>>>>> lectures, archives, unsubscribe, maps at http://www.friam.org >>>>>> >>>>> ============================================================ >>>>> FRIAM Applied Complexity Group listserv >>>>> Meets Fridays 9a-11:30 at cafe at St. John's College >>>>> lectures, archives, unsubscribe, maps at http://www.friam.org >>>>> >>>> ============================================================ >>>> FRIAM Applied Complexity Group listserv >>>> Meets Fridays 9a-11:30 at cafe at St. John's College >>>> lectures, archives, unsubscribe, maps at http://www.friam.org >>>> >>> ============================================================ >>> FRIAM Applied Complexity Group listserv >>> Meets Fridays 9a-11:30 at cafe at St. John's College >>> lectures, archives, unsubscribe, maps at http://www.friam.org >>> >> =================================== >> Jim Rutt >> voice: 505-989-1115 >> >> >> >> ============================================================ >> FRIAM Applied Complexity Group listserv >> Meets Fridays 9a-11:30 at cafe at St. John's College >> lectures, archives, unsubscribe, maps at http://www.friam.org >> > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > |
Python Development Environment?
|
|
In reply to this post by Robert Holmes-2
At 02:31 PM 2/28/2006 -0700, you wrote:
>I hate to admit it but I do pretty much everything with vi and print >statements. > >Ruby rocks, btw. But then I still love Perl, and I do pretty much >everything with vi and print statements, so, you know, grain of salt >type thing. > >As far as I can tell Python's big strength over Ruby (in large >corporate settings at least) is its **lack** of flexibility. It's >supposed to ease maintenance and improve performance. "Perlish" seems >to be a bad word among hardcore Python types, and Ruby does give you a >lot of Perlish freedoms. The problem with Perlish freedoms, as far as >I understand it, is that they can be unexpected and weird to debug. >But the upside is that they're lots of fun. Also, it seems a lot of >the buzz on Ruby is driven by the buzz on Rails, and Rails takes a lot >of advantage of Ruby's dynamic features. It might have been much, much >more cumbersome if it had been written in Python. Python, improve performance, what the hell are you talking about? Python is slow. Slower than Perl for more than half the tasks measured at http://shootout.alioth.debian.org/. "Large corporate settings" ? Large corporations don't use Python to develop anything except little toy apps. One person said I was Obsessive Compulsive to talk about just one of the features that makes Python such a joke. Real programmers do NOT need a formatting tool to read code. They can read it if some other programmer chose to dump multiple statements into one line. It doesn't matter to them. The "there's only one way to do it" mentality is demeaning; real programmers try to find the fastest of the possible ways to do a task. Sounds to me that Python is for people that really shouldn't have strayed from BASIC and other luser types. BTW, Ruby is much slower than Python for most tasks, but it's the flexibility that is often very useful. >I've only done a few toy projects in either Python or Ruby at the >moment, so I couldn't comment beyond that, really, but I do share >Martin's curiousity. > >Oh yeah, and Smalltalk? Please. Smalltalk is like so mainstream. It's >all about CLU and Eiffel. Get with the times, man. I am "with the times". >-- >Giles Goat Boy > >http://gilesmakesmusic.blogspot.com >http://gileswritescode.blogspot.com > >============================================================ >FRIAM Applied Complexity Group listserv >Meets Fridays 9a-11:30 at cafe at St. John's College >lectures, archives, unsubscribe, maps at http://www.friam.org |
|
|
In reply to this post by Owen Densmore
I am sure that Python proponents would have a bit to say about this.
But I haven't drunk the kool aid yet and have no way to judge what is more "pythonic" as they like to say. I think what is more important is that python gives you an interactive prompt to fiddle with your objects with. I also like the concise expressiveness of the syntax. Perl to me seems way too cryptic and hard to read, too clever by half in many idioms with all its many shortcuts. Python has less of this but remains very concise. I can't see a drawback to bringing this sort of language into the Java realm. I haven't ever enjoyed dealing with Swing type stuff in Java but a couple of sessions with an interactive Jython prompt sure helped me understand Swing a lot better. I really enjoy the immediacy you can get from an interactive console. For me the edit/compile/run cycle gets in the way. On Mar 1, 2006, at 2:56 PM, Owen Densmore wrote: > Josh: Lets suppose, by some miracle, the Groovy folks actually settle > down and build a system that is mature and usable. For folks who > haven't seen it: > http://groovy.codehaus.org/ > Its very Ruby/Python-like and lets you access all of Java. > > Would it then satisfy Bruce and others like yourself wanting an > nimble, agile language? (From what I can tell, its performance is > roughly the same as Ruby/Python.) Or are there other features of the > Python language/world/community that are more important? > > -- Owen > > Owen Densmore > http://backspaces.net - http://redfish.com - http://friam.org > > > On Mar 1, 2006, at 10:42 AM, Joshua Thorp wrote: > >> This snippet from an interview http://www.artima.com/intv/ >> aboutme.html with Bruce Eckel about Python hit what I am looking for >> in a language: >> >> Bill Venners: In your keynote, you gave ten reasons you love Python. >> Number ten was reduced clutter. What did you mean by reduced clutter? >> >> Bruce Eckel: They say you can hold seven plus or minus two pieces of >> information in your mind. I can't remember how to open files in Java. >> I've written chapters on it. I've done it a bunch of times, but it's >> too many steps. And when I actually analyze it, I realize these are >> just silly design decisions that they made. Even if they insisted on >> using the Decorator pattern in java.io, they should have had a >> convenience constructor for opening files simply. Because we open >> files all the time, but nobody can remember how. It is too much >> information to hold in your mind. > > ... snip ... > > ============================================================ > FRIAM Applied Complexity Group listserv > Meets Fridays 9a-11:30 at cafe at St. John's College > lectures, archives, unsubscribe, maps at http://www.friam.org |
Python Development Environment?
|
|
In reply to this post by Giles Bowkett
Hmmm, you'll have to tell J.P. Morgan, a number of other large investment
companies, a large rail system, the largest processor of debit card transactions, and FedEx. I'm sure they'd laugh their asses off. I won't even mention any of my current clients (none of the above) because I'd rather you remain ignorant. At most places I'm aware of that have both Smalltalk and Java staff , the Smalltalk staff is not only smaller, but it's more productive than the Java staff. I can't even talk about the uselessness of Python as a "real world" skill. There's almost no demand for Python programmers AFAIK. If there is, please point out the job listings (Monster, Dice, whatever) that show otherwise. I'm reminded of a former boss who was so narrow-minded that he could see through a keyhole with both eyes. At 10:09 AM 3/1/2006 -0700, Douglas Roberts wrote: >I found myself supressing an urge to lash back at the smalltalk suggestion >as well. Smalltalk is interesting from a purely academic perspective. It >is *not* an appropriate language for developing real-world applications. > >--Doug |
Python Development Environment?
|
|
In reply to this post by John Pfersich
After your subsequent post, I can't be bothered. I had been preparing
something, but you're not worth it. At 09:50 AM 3/1/2006 -0700, you wrote: >Hey John, sorry for razzing you about Smalltalk, to be honest I'm >looking for a good Smalltalk learning resource. I downloaded Cincom >VisualWorks Smalltalk a while ago but I really haven't done anything >other than skimming the intro stuff and playing with the IDE and its >object library. Any pointers for a n00b? > >On 2/28/06, John Pfersich <jp1660 at att.net> wrote: > > At 09:58 AM 2/28/2006 -0700, Owen wrote: > > >We've been looking into using Python in some modeling efforts. One > > >question we stumble across is "What's a good Development Environment?" > > > > > >So what are your experiences? Eclipse + PyDev? Eclipse + > > >TruStudio? Boa Constructor? WingWare? Vanilla syntax oriented > > >programming editor? It'd be sweet if it were cross-platform, running > > >on Windows, Mac and Linux so we can all share the pain! > > > > I use jEdit as a vanilla syntax oriented editor. It's cross-platform > > (written in Java) and has quite a large number of add-on modules. It may > > have Python oriented add-ons; I don't use Python (ugh). > > > > Why not try Ruby if you're starting from scratch? Python has some nasty > > column-based formatting rules that I find too reminiscent of my old punch > > card days (or is it daze). I'd say that Ruby's a better choice unless > > there's some Python libraries that would be useful. Quite a few OO > > luminaries have jumped on the Ruby bandwagon over the past few years. I've > > been a Rubyist for a couple of years (I first tried Ruby in 2001), and I > > find the language to be OK. I still prefer Smalltalk. > > > > GNU Smalltalk is much like Ruby, but usually faster (sometimes much faster > > than it or Python) and the code can be transferred to other Smalltalks > > (like Squeak, Cincom VisualWorks, the ex-IBM VAST, or the Windows only > > Dolphin ST and quite a few others) pretty easily. With Smalltalk you'll > > definitely get a visual debugger in the environment (except for GST) that > > will allow you to fix the code and restart the process in real time. > > Eclipse is based on the Smalltalk environment (as are all IDEs, AFAIK), and > > Eclipse is a really lame imitation of the Smalltalk environment. > > > > It all comes down to which language will fit your needs best. > > > > >One issue is debugging: we'd like a visual debugger with single > > >stepping and break points if at all possible. > > > > > > -- Owen > > > > > > ============================================================ > > FRIAM Applied Complexity Group listserv > > Meets Fridays 9a-11:30 at cafe at St. John's College > > lectures, archives, unsubscribe, maps at http://www.friam.org > > > > >-- >Giles Goat Boy > >http://gilesmakesmusic.blogspot.com >http://gileswritescode.blogspot.com |
|
|
In reply to this post by Jim Rutt
Here's a pointer to an article that satirizes language lovers personality
types: Programming languages and their relationship styles http://maradydd.livejournal.com/293666.html |
«
Return to Friam
|
1 view|%1 views
| Free forum by Nabble | Edit this page |