What is different with Python ?

[Philippe C. Martin]

I apologize in advance for launching this post but I might get enlightment
somehow (PS: I am _very_ agnostic ;-).

- 1) I do not consider my intelligence/education above average
- 2) I am very pragmatic
- 3) I usually move forward when I get the gut feeling I am correct
- 4) Most likely because of 1), I usually do not manage to fully explain 3)
when it comes true.
- 5) I have developed for many years (>18) in many different environments,
languages, and O/S's (including realtime kernels) .


Yet for the first time I get (most) of my questions answered by a language I
did not know 1 year ago.

As I do try to understand concepts when I'm able to, I wish to try and find
out why Python seems different.

Having followed this newsgroup for sometimes, I now have the gut feeling
(see 3)) other people have that feeling too.


Quid ?

Regards,

Philippe

[Martin v. Löwis]

Re: What is different with Python ?

Philippe C. Martin wrote:[color=blue]
> I apologize in advance for launching this post but I might get enlightment
> somehow (PS: I am _very_ agnostic ;-).
>
> - 1) I do not consider my intelligence/education above average
> - 2) I am very pragmatic
> - 3) I usually move forward when I get the gut feeling I am correct
> - 4) Most likely because of 1), I usually do not manage to fully explain 3)
> when it comes true.
> - 5) I have developed for many years (>18) in many different environments,
> languages, and O/S's (including realtime kernels) .
>
>
> Yet for the first time I get (most) of my questions answered by a language I
> did not know 1 year ago.
>
> As I do try to understand concepts when I'm able to, I wish to try and find
> out why Python seems different.[/color]

Unfortunately, you didn't give many examples of what you did for the
last 18 years (except that that also included RT kernels).

So let me guess two aspects:

1. In these 18 years, you got acquainted to a variety of concepts
in various languages. When dealing with Python, you could easily
correlate between Python concepts and the ones you are familiar
with. This is one of Python's strenghts: it tries not to be
surprising, but builds on what most people consider standard.
Try "import this" some time; you may be experiencing the Zen:

Readability counts.
...
Special cases aren't special enough to break the rules.
Although practicality beats purity.
...
In the face of ambiguity, refuse the temptation to guess.

2. You may not have dealt with a weakly-typed language before. If
that is the case, your feeling of "something being different"
most likely comes from that difference.

Regards,
Martin

[Robert Kern]

Re: What is different with Python ?

Philippe C. Martin wrote:[color=blue]
> I apologize in advance for launching this post but I might get enlightment
> somehow (PS: I am _very_ agnostic ;-).
>
> - 1) I do not consider my intelligence/education above average
> - 2) I am very pragmatic
> - 3) I usually move forward when I get the gut feeling I am correct
> - 4) Most likely because of 1), I usually do not manage to fully explain 3)
> when it comes true.
> - 5) I have developed for many years (>18) in many different environments,
> languages, and O/S's (including realtime kernels) .
>
> Yet for the first time I get (most) of my questions answered by a language I
> did not know 1 year ago.[/color]

I cannot understand this sentence. What questions? Which language?

Do you mean that, currently, when you need to solve a problem, you
usually use Python even though you are relatively new to it? And that
before learning Python you usually used a variety of languages, none
dominating the others?
[color=blue]
> As I do try to understand concepts when I'm able to, I wish to try and find
> out why Python seems different.[/color]

Python is my language of choice because it doesn't get in the way. I
don't have to contort my problem into strict class heirarchies or
recursive functions. I don't have to construct the whole system to test
just a part of it. The interactive prompt has become vital to my
workflow. By and large, I just Get It Done.

The "one and preferably only one obvious way to do it" principle and
Python's emphasis on readability means that I gain knowledge and
capability as I write code. When I need to do a similar task six months
later, I don't have to spend an inordinate amount of time figuring out
what the hell I was thinking back then. In the same vein, I can also
read and learn from others' code much more than I could from, say, Perl.

--
Robert Kern
rkern@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Peter Hansen]

Re: What is different with Python ?

Martin v. Löwis wrote:[color=blue]
> Philippe C. Martin wrote:[color=green]
>>- 5) I have developed for many years (>18) in many different environments,
>>languages, and O/S's (including realtime kernels) .[/color]
>
> 2. You may not have dealt with a weakly-typed language before. If
> that is the case, your feeling of "something being different"
> most likely comes from that difference.[/color]

If he's done realtime kernels, he's most definitely worked with a weakly
typed language before (assembly most likely), but I think you meant to
say (or should have said) "dynamicall y typed".

-Peter

[Claudio Grondi]

Re: What is different with Python ?

Re: What is different with Python ?

from my point of view, to be honest, nothing
except mixing a well spiced soup of what
was available within other programming
languages.

I think, that what currently makes a real
difference is not the language as such,
but the people using it, posting here and
writing new modules for it.

I can imagine, that with becoming more
popular and less supported by the
core development team (following a
special kind of programming philosophy
called "Pythonic way" of approaching
things) this can change, so I can only hope,
that this won't happen.

Don't ask _me_ what "Pythonic way" is -
I think, you have to feel it yourself in order to
understand it (I haven't yet seen any definition
of it different from what is already also known
from other programming languages, but maybe
someone can provide it?).

by the way: I see a contradiction between[color=blue]
> - 1) I do not consider my intelligence/education above average[/color]
and[color=blue]
> - 5) I have developed for many years (>18) in many different environments,
> languages, and O/S's (including realtime kernels) .[/color]
because - 5) is the story many of programmers choosing Python
as a tool or programming language of their choice went through
and because of the fact you are here asking that question.

Claudio

"Philippe C. Martin" <philippe@phili ppecmartin.com> schrieb im Newsbeitrag
news:bXGqe.2582 $751.2437@newss vr30.news.prodi gy.com...[color=blue]
> I apologize in advance for launching this post but I might get enlightment
> somehow (PS: I am _very_ agnostic ;-).
>
> - 1) I do not consider my intelligence/education above average
> - 2) I am very pragmatic
> - 3) I usually move forward when I get the gut feeling I am correct
> - 4) Most likely because of 1), I usually do not manage to fully explain[/color]
3)[color=blue]
> when it comes true.
> - 5) I have developed for many years (>18) in many different environments,
> languages, and O/S's (including realtime kernels) .
>
>
> Yet for the first time I get (most) of my questions answered by a language[/color]
I[color=blue]
> did not know 1 year ago.
>
> As I do try to understand concepts when I'm able to, I wish to try and[/color]
find[color=blue]
> out why Python seems different.
>
> Having followed this newsgroup for sometimes, I now have the gut feeling
> (see 3)) other people have that feeling too.
>
>
> Quid ?
>
> Regards,
>
> Philippe
>
>
>
>
>
>
>
>
>
>[/color]

[Philippe C. Martin]

Re: What is different with Python ?

Thanks ,
I have gotten many answers already, some not posted.

1) Typing is not the issue - even with RT-Kernels, people use C++
2) Yes I find dynamic binding very nice
3) "... you didn't give many examples of what you did for the
last 18 years (except that that also included RT kernels). ...." assembly
(losts) , basic, cobol, lisp, JAVA, c, c++, perl, Tcl, Java, JavaCard .....

I know the "interactiv e" aspect helps also, the runtime error/exception
checking, the many libraries/tools, the responsiveness of the people on
this newsgroup, the "introspectiven ess" of the system, the cross-platform
it deals with, the way it "pushes" people to code in a clean way, the GUI
support, the stability, the extensibility (in and out) .... I'm sure you'll
agree none of that can explain why after 1 week of playing with, I was more
productive in Python than C/C++ just as I know my product (I will not
describe it here as I am not marketing) would not exist today were it not
for Python.
4) Yes I agree a mix ("... well spiced soup ...") seems to be the answer but
my brain somehow wants to formalize it.

Regards,

Philippe





Philippe C. Martin wrote:
[color=blue]
> I apologize in advance for launching this post but I might get enlightment
> somehow (PS: I am _very_ agnostic ;-).
>
> - 1) I do not consider my intelligence/education above average
> - 2) I am very pragmatic
> - 3) I usually move forward when I get the gut feeling I am correct
> - 4) Most likely because of 1), I usually do not manage to fully explain
> 3) when it comes true.
> - 5) I have developed for many years (>18) in many different environments,
> languages, and O/S's (including realtime kernels) .
>
>
> Yet for the first time I get (most) of my questions answered by a language
> I did not know 1 year ago.
>
> As I do try to understand concepts when I'm able to, I wish to try and
> find out why Python seems different.
>
> Having followed this newsgroup for sometimes, I now have the gut feeling
> (see 3)) other people have that feeling too.
>
>
> Quid ?
>
> Regards,
>
> Philippe[/color]

[Claudio Grondi]

Re: What is different with Python ?

> 4) Yes I agree a mix ("... well spiced soup ...")[color=blue]
> seems to be the answer but
> my brain somehow wants to formalize it.[/color]

Here one further suggestion trying to point out, that
it probably can't generally be formalized, because
the experience one developes after going through
the story of "assembly, basic, cobol, lisp,
JAVA, c, c++, perl, Tcl, Java, JavaCard" has
in my opinion a vital impact on shortcuts one uses
and the way of doing things. I mean, that the concept
of Python has raised from such experience, so anyone
who went through all this, will get the core ideas
implemented in Python without any effort, because
they were already there as a kind of meta-language
used in thinking, unconsciously looking for the
chance of beeing expressed in formalized form
as a new programming language.
To support my thesis I can mention here, that
from my experience, Python seems not to be
the language of choice for the very beginners,
who prefere another approaches which are
mostly variants of Basic.

Claudio

"Philippe C. Martin" <philippe@phili ppecmartin.com> schrieb im Newsbeitrag
news:GhIqe.3677 $%j7.513@newssv r11.news.prodig y.com...[color=blue]
> Thanks ,
> I have gotten many answers already, some not posted.
>
> 1) Typing is not the issue - even with RT-Kernels, people use C++
> 2) Yes I find dynamic binding very nice
> 3) "... you didn't give many examples of what you did for the
> last 18 years (except that that also included RT kernels). ...." assembly
> (losts) , basic, cobol, lisp, JAVA, c, c++, perl, Tcl, Java, JavaCard[/color]
......[color=blue]
>
> I know the "interactiv e" aspect helps also, the runtime error/exception
> checking, the many libraries/tools, the responsiveness of the people on
> this newsgroup, the "introspectiven ess" of the system, the cross-platform
> it deals with, the way it "pushes" people to code in a clean way, the GUI
> support, the stability, the extensibility (in and out) .... I'm sure[/color]
you'll[color=blue]
> agree none of that can explain why after 1 week of playing with, I was[/color]
more[color=blue]
> productive in Python than C/C++ just as I know my product (I will not
> describe it here as I am not marketing) would not exist today were it not
> for Python.
> 4) Yes I agree a mix ("... well spiced soup ...") seems to be the answer[/color]
but[color=blue]
> my brain somehow wants to formalize it.
>
> Regards,
>
> Philippe
>
>
>
>
>
> Philippe C. Martin wrote:
>[color=green]
> > I apologize in advance for launching this post but I might get[/color][/color]
enlightment[color=blue][color=green]
> > somehow (PS: I am _very_ agnostic ;-).
> >
> > - 1) I do not consider my intelligence/education above average
> > - 2) I am very pragmatic
> > - 3) I usually move forward when I get the gut feeling I am correct
> > - 4) Most likely because of 1), I usually do not manage to fully explain
> > 3) when it comes true.
> > - 5) I have developed for many years (>18) in many different[/color][/color]
environments,[color=blue][color=green]
> > languages, and O/S's (including realtime kernels) .
> >
> >
> > Yet for the first time I get (most) of my questions answered by a[/color][/color]
language[color=blue][color=green]
> > I did not know 1 year ago.
> >
> > As I do try to understand concepts when I'm able to, I wish to try and
> > find out why Python seems different.
> >
> > Having followed this newsgroup for sometimes, I now have the gut feeling
> > (see 3)) other people have that feeling too.
> >
> >
> > Quid ?
> >
> > Regards,
> >
> > Philippe[/color]
>[/color]

[Philippe C. Martin]

Re: What is different with Python ?

I agree '...choice for the very beginners ...': a hundred year ago I was a
Pascal TA, and although I like the language, I find/found people stuggled
as much with the language as with the algorithm they were supposed to
implement.

"...mostly variants of Basic..." What I truly liked going from Basic (which
has greatly evolved) to Pascal was the fact I found a definite risk not
having to declare variable/ or rather I understood the lack of danger in
doing so: The one (so I thought) glitch with Python that almost made me
stop playing with was that very fact. yet I agree a complete beginner would
simply the approach most meaningful "why should I write int i = 1 since I
know 1 is an int". Since the "dangers" of old basic are gone from Python
(can't do i=y if y has not ever been initialized). I must agree with that
too. I'm actually pushing the few CS professors I know to use Python for CS
101. Yet, many issues that a future software engineer should know are
mostly hidden by Python (ex: memory management) and that could be
detrimental.

Regards,

Philippe






Claudio Grondi wrote:
[color=blue][color=green]
>> 4) Yes I agree a mix ("... well spiced soup ...")
>> seems to be the answer but
>> my brain somehow wants to formalize it.[/color]
>
> Here one further suggestion trying to point out, that
> it probably can't generally be formalized, because
> the experience one developes after going through
> the story of "assembly, basic, cobol, lisp,
> JAVA, c, c++, perl, Tcl, Java, JavaCard" has
> in my opinion a vital impact on shortcuts one uses
> and the way of doing things. I mean, that the concept
> of Python has raised from such experience, so anyone
> who went through all this, will get the core ideas
> implemented in Python without any effort, because
> they were already there as a kind of meta-language
> used in thinking, unconsciously looking for the
> chance of beeing expressed in formalized form
> as a new programming language.
> To support my thesis I can mention here, that
> from my experience, Python seems not to be
> the language of choice for the very beginners,
> who prefere another approaches which are
> mostly variants of Basic.
>
> Claudio
>
> "Philippe C. Martin" <philippe@phili ppecmartin.com> schrieb im Newsbeitrag
> news:GhIqe.3677 $%j7.513@newssv r11.news.prodig y.com...[color=green]
>> Thanks ,
>> I have gotten many answers already, some not posted.
>>
>> 1) Typing is not the issue - even with RT-Kernels, people use C++
>> 2) Yes I find dynamic binding very nice
>> 3) "... you didn't give many examples of what you did for the
>> last 18 years (except that that also included RT kernels). ...." assembly
>> (losts) , basic, cobol, lisp, JAVA, c, c++, perl, Tcl, Java, JavaCard[/color]
> .....[color=green]
>>
>> I know the "interactiv e" aspect helps also, the runtime error/exception
>> checking, the many libraries/tools, the responsiveness of the people on
>> this newsgroup, the "introspectiven ess" of the system, the cross-platform
>> it deals with, the way it "pushes" people to code in a clean way, the GUI
>> support, the stability, the extensibility (in and out) .... I'm sure[/color]
> you'll[color=green]
>> agree none of that can explain why after 1 week of playing with, I was[/color]
> more[color=green]
>> productive in Python than C/C++ just as I know my product (I will not
>> describe it here as I am not marketing) would not exist today were it not
>> for Python.
>> 4) Yes I agree a mix ("... well spiced soup ...") seems to be the answer[/color]
> but[color=green]
>> my brain somehow wants to formalize it.
>>
>> Regards,
>>
>> Philippe
>>
>>
>>
>>
>>
>> Philippe C. Martin wrote:
>>[color=darkred]
>> > I apologize in advance for launching this post but I might get[/color][/color]
> enlightment[color=green][color=darkred]
>> > somehow (PS: I am _very_ agnostic ;-).
>> >
>> > - 1) I do not consider my intelligence/education above average
>> > - 2) I am very pragmatic
>> > - 3) I usually move forward when I get the gut feeling I am correct
>> > - 4) Most likely because of 1), I usually do not manage to fully
>> > explain 3) when it comes true.
>> > - 5) I have developed for many years (>18) in many different[/color][/color]
> environments,[color=green][color=darkred]
>> > languages, and O/S's (including realtime kernels) .
>> >
>> >
>> > Yet for the first time I get (most) of my questions answered by a[/color][/color]
> language[color=green][color=darkred]
>> > I did not know 1 year ago.
>> >
>> > As I do try to understand concepts when I'm able to, I wish to try and
>> > find out why Python seems different.
>> >
>> > Having followed this newsgroup for sometimes, I now have the gut
>> > feeling (see 3)) other people have that feeling too.
>> >
>> >
>> > Quid ?
>> >
>> > Regards,
>> >
>> > Philippe[/color]
>>[/color][/color]

[Tom Anderson]

Re: What is different with Python ?

On Sat, 11 Jun 2005, Philippe C. Martin wrote:
[color=blue]
> Yet for the first time I get (most) of my questions answered by a
> language I did not know 1 year ago.[/color]

Amazing, isn't it? Rest assured that you're not alone in feeling this way.
I don't know quite why, but python is just makes writing programs
immensely easier than any other language i've ever used; i think it's the
very minimal amount of boilerplate it requires, the clean and powerful set
of builtin types and functions and, for me, the higher-order functions. I
can do in a few lines of python what would have taken me pages and pages
of java.

tom

PS: http://jove.prohosting.com/~zahlman/cpp.html

--
Jim-Jammity Jesus Krispy Kreme Christ on a twat-rocket!

[Philippe C. Martin]

Re: What is different with Python ?

> PS: http://jove.prohosting.com/~zahlman/cpp.html

So you're saying they only use perl in Taiwan ;-)



Tom Anderson wrote:
[color=blue]
> On Sat, 11 Jun 2005, Philippe C. Martin wrote:
>[color=green]
>> Yet for the first time I get (most) of my questions answered by a
>> language I did not know 1 year ago.[/color]
>
> Amazing, isn't it? Rest assured that you're not alone in feeling this way.
> I don't know quite why, but python is just makes writing programs
> immensely easier than any other language i've ever used; i think it's the
> very minimal amount of boilerplate it requires, the clean and powerful set
> of builtin types and functions and, for me, the higher-order functions. I
> can do in a few lines of python what would have taken me pages and pages
> of java.
>
> tom
>
> PS: http://jove.prohosting.com/~zahlman/cpp.html
>[/color]

[Peter Hansen]

Re: What is different with Python ?

Philippe C. Martin wrote:[color=blue]
> too. I'm actually pushing the few CS professors I know to use Python for CS
> 101. Yet, many issues that a future software engineer should know are
> mostly hidden by Python (ex: memory management) and that could be
> detrimental.[/color]

I think new CS students have more than enough to learn with their
*first* language without having to discover the trials and tribulations
of memory management (or those other things that Python hides so well).

Simple concepts like variables, control structures, input and output are
more than enough to start with. In fact, I suspect any course that
attempts to teach with a language that requires things like manual
memory management will be failing to provide an effective grounding in
computer science because of all the noise. Seeing the forest for the
trees and all that...

-Peter

[Roy Smith]

Re: What is different with Python ?

"Philippe C. Martin" <philippe@phili ppecmartin.com> wrote:[color=blue]
> Yet, many issues that a future software engineer should know are
> mostly hidden by Python (ex: memory management) and that could be
> detrimental.[/color]

I know I'm going out on a limb by asking this, but why do you think future
software engineers should know about memory management?

I used to worry about register allocation. Today, I don't even know how
many registers any machine I work on has. I used to worry about word size,
and byte order. I used to worry about whether stacks grew up or down and
addressing modes and floating point formats. Sure, somebody's got to worry
about those things, but most people who write software can be blissfully
ignorant (or, at best, dimly aware) of these issues because somebody else
(compiler writer, hardware designer, operating system writer, etc) has
already done the worrying.

There used to be a time when you had to worry about how many tracks to
allocate when you created a disk file. When's the last time you worried
about that?

[John Machin]

Re: What is different with Python ?

Roy Smith wrote:[color=blue]
> "Philippe C. Martin" <philippe@phili ppecmartin.com> wrote:
>[color=green]
>>Yet, many issues that a future software engineer should know are
>>mostly hidden by Python (ex: memory management) and that could be
>>detrimental .[/color]
>
>
> I know I'm going out on a limb by asking this, but why do you think future
> software engineers should know about memory management?[/color]

Perhaps we have a terminology problem here i.e. different meanings of
"software engineer". Philippe started talking about "CS" courses,
whereas you may be referring to people who have done an "IT" course or
achieved a certification in the use of app development tool X.
[color=blue]
>
> I used to worry about register allocation. Today, I don't even know how
> many registers any machine I work on has. I used to worry about word size,
> and byte order. I used to worry about whether stacks grew up or down and
> addressing modes and floating point formats. Sure, somebody's got to worry
> about those things, but most people who write software can be blissfully
> ignorant (or, at best, dimly aware) of these issues because somebody else
> (compiler writer, hardware designer, operating system writer, etc) has
> already done the worrying.[/color]

You would hope they'd done more than worry about it. However sometimes
one's fondest hopes are dashed. You must have noticed the anguish in the
timbot's posts that mention Windows 95 memory management.
[color=blue]
>
> There used to be a time when you had to worry about how many tracks to
> allocate when you created a disk file. When's the last time you worried
> about that?[/color]

Seeing you asked: early 1970s, on an IBM 1800. But much more recently it
certainly helped if one were slightly more than dimly aware of the
difference between a FAT filesystem and an NTFS filesystem :-)

Cheers,
John

[Mike Meyer]

Re: What is different with Python ?

John Machin <sjmachin@lexic on.net> writes:[color=blue]
> Roy Smith wrote:[color=green]
>> "Philippe C. Martin" <philippe@phili ppecmartin.com> wrote:[color=darkred]
>>>Yet, many issues that a future software engineer should know are
>>>mostly hidden by Python (ex: memory management) and that could be
>>>detrimenta l.[/color]
>> I know I'm going out on a limb by asking this, but why do you think
>> future software engineers should know about memory management?[/color]
> Perhaps we have a terminology problem here i.e. different meanings of
> "software engineer". Philippe started talking about "CS" courses,
> whereas you may be referring to people who have done an "IT" course or
> achieved a certification in the use of app development tool X.[/color]

While I agree with John - software engineers should know something
about memory managment - I sort of agree with Roy as well, in that,
like Peter, I think memory management is something that doesn't need
to be taught immediately. A modern programming environment should take
care of the details, but a software engineer will be cognizant of the
details, and know enough to know when they have to worry about it and
when they can safely ignore it.
[color=blue][color=green]
>> I used to worry about register allocation. Today, I don't even know
>> how many registers any machine I work on has. I used to worry about
>> word size, and byte order. I used to worry about whether stacks
>> grew up or down and addressing modes and floating point formats.
>> Sure, somebody's got to worry about those things, but most people
>> who write software can be blissfully ignorant (or, at best, dimly
>> aware) of these issues because somebody else (compiler writer,
>> hardware designer, operating system writer, etc) has already done
>> the worrying.[/color]
> You would hope they'd done more than worry about it. However sometimes
> one's fondest hopes are dashed. You must have noticed the anguish in
> the timbot's posts that mention Windows 95 memory management.[/color]

I think most of those things are indeed things that your average
software engineer can ignore 90+% of the time. What makes someone a
software engineer is that they know about those details, and know how
they will affect the code they are writing - and hence when they have
to worry about those details.

Oddly enough, I find similar comments apply to a lot of the data
structures I learned in school. I recently applied for a job that had
a series of essay questions in the application. They had a series of
problems with requests for solutions, and my immediate reaction to
each was to reach for off-the-shelf software to solve the
problem. While they wanted - and I provided - a discussion of data
structures and big-O running time for various operations, all the
things they wanted to do were essentially solved problems, and there
was debugged and tuned code available to deal with things - and it's
much faster to not write software if you can to solve the problem.

For instance, one problem was "You have two files that have lists of 1
billion names in them. Print out a list of the names that only occur
in one of the files."

That's a one-line shell script: "comm -12 <(sort file_one) <(sort file_two)"

I gave them that answer. I also gave them a pseudo-code solution, but
frankly, in real life, I'd install the shell script and get on with
things. If I were hiring someone, I'd hire the person who gave me the
shell script. Rather than spending hours/days debugging a program to
solve the problem, I get a solution in minutes. If it runs into
problems, *then* it's time to start hand coding the solution.
[color=blue][color=green]
>> There used to be a time when you had to worry about how many tracks
>> to allocate when you created a disk file. When's the last time you
>> worried about that?[/color]
> Seeing you asked: early 1970s, on an IBM 1800. But much more recently
> it certainly helped if one were slightly more than dimly aware of the
> difference between a FAT filesystem and an NTFS filesystem :-)[/color]

For me it was the late 1970s, on an IBM 3081. But I was worried about
disk sector sizes well into the 1990s. Since then I've worked on
systems that didn't have a file system as such; it had a database of
databases, and you queried the former to find the latter.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Philippe C. Martin]

Re: What is different with Python ?

I guess because I have mostly worked with embedded systems and that,
although I have always tried to put abstraction layers between my
applications and the hardware, some constraints still remain at the
application level: (memory, determinism, re-entrance,...). You will notice
that 99% of the embedded systems with realtime constaints use assembly,
C/C++, or ADA.

I agree with you and Peter though that these issues need not be treated on a
first course. Yet, and depending on the ultimate goal (John spoke of IT
versus CS) some of the newly trained folks should know about it. We could
not enjoy Python if no one were here to implement its VM, I have not looked
at the code, but I gather it is fairly complex and does require an amount
of "low level" skills.

Regards,

Philippe



Roy Smith wrote:
[color=blue]
> "Philippe C. Martin" <philippe@phili ppecmartin.com> wrote:[color=green]
>> Yet, many issues that a future software engineer should know are
>> mostly hidden by Python (ex: memory management) and that could be
>> detrimental.[/color]
>
> I know I'm going out on a limb by asking this, but why do you think future
> software engineers should know about memory management?
>
> I used to worry about register allocation. Today, I don't even know how
> many registers any machine I work on has. I used to worry about word
> size,
> and byte order. I used to worry about whether stacks grew up or down and
> addressing modes and floating point formats. Sure, somebody's got to
> worry about those things, but most people who write software can be
> blissfully ignorant (or, at best, dimly aware) of these issues because
> somebody else (compiler writer, hardware designer, operating system
> writer, etc) has already done the worrying.
>
> There used to be a time when you had to worry about how many tracks to
> allocate when you created a disk file. When's the last time you worried
> about that?[/color]