HELP! Must choose language!
Chewdip20
programming. I realize I waited too long to begin, as many have started in
earlier grades, but I am determined to learn something. But that is where it
stops. I have no idea what programming language to learn. This, for me, as a
beginner, is incredibly frustrating and I keep questioning myself. WHAT is the
best language to learn, in your unbiased opinion, for a complete beginner to
programming? I have seriously considered C( I even bought and started on a book
about it), Python(my original choice, however, teachers deterred me from it),
C++(instead of C, supposedly quicker to get into), as well as some form of
BASIC. But I, in all seriousness, am running out of time. I get back to school
the week after next, and I want to have some intermediate knowledge of a
language by then. I get little time to do anything I want after school, and
thus my chances to further my knowledge of a language would be severly limited
to weekends, which are also packed for me. Basically, everyone, I need a
language, I need it fast.
Also, I have heard C and C++ are rough to start with. Any truth to this?
I have heard from several sources how helpful this newsgroup is, so I came here
for you guys' experience. Thanks for any help,
Qweezle.
Chewdip20
that into consideration.
;-)
Terry Reedy
> beginner, is incredibly frustrating and I keep questioning myself.
WHAT is the
> best language to learn, in your unbiased opinion, for a complete
beginner to
> programming?
You will get a somewhat biased answer on any newsgroup.
Have you gone through the tutorial yet? If not, do so. Or look at
some of the other beginner materials. Have you download and installed
the Python interpreter yet? If not, do so. Use the interactive mode
to experiment and learn. This possibility alone is a reason to choose
Python over other languages that lack this advantage.
Terry J. Reedy
William Park
> Hello, everyone, I am a 9th grade student, who is very interested in
Not too late. In fact, it's a bit early.
> learning programming. I realize I waited too long to begin, as many
> have started in earlier grades, but I am determined to learn
> something. But that is where it stops. I have no idea what programming
> language to learn. This, for me, as a beginner, is incredibly
> frustrating and I keep questioning myself. WHAT is the best language
> to learn, in your unbiased opinion, for a complete beginner to
> programming? I have seriously considered C( I even bought and started
History of language evolved from C to Python. But, for learning, you
can go backward. But, no matter what, you should know both C and
Python.
> on a book about it), Python(my original choice, however, teachers
> deterred me from it), C++(instead of C, supposedly quicker to get
> into), as well as some form of BASIC. But I, in all seriousness, am
> running out of time. I get back to school the week after next, and I
> want to have some intermediate knowledge of a language by then. I get
> little time to do anything I want after school, and thus my chances to
> further my knowledge of a language would be severly limited to
> weekends, which are also packed for me. Basically, everyone, I need a
> language, I need it fast. Also, I have heard C and C++ are rough to
> start with. Any truth to this?
C++ takes years. But, you can pick up C or Python in one week, and be
comfortable in one month.
Your choice, however, would depend on whatever language that is used in
your computer course.
>
> I have heard from several sources how helpful this newsgroup is, so I
> came here for you guys' experience. Thanks for any help,
--
William Park, Open Geometry Consulting, <openge...@yahoo.ca>
Linux solution for data management and processing.
Hrvoje Nezic
I have a very long experience in programming in different
languages. For long time I programmed in C.
Then I become familiar with object oriented programming
through Smalltalk. When C++ compilers appeared I
started to program in C++ and I do it now, not
because this is my decision, but because my company
forces me to do so. If I could choose by myself, I
would never, never choose C++ (after having long experience
in using it). I am also familiar with Java and C#.
If I would choose by myself I would choose
Eiffel or Python. These are my two favorite programming
languages. I didn't find time so far to explore functional
languages like Haskell. I use Python for my personal
projects.
It would be difficult to give *completely* unbiased
opinion, but I think that certain aspects of
various programming languages could be rationally
compared.
When choosing your first language some of your
characteristics can be very important, too. If you like
elegance and consistency you would be satisfied
with certain kind of programming languages. If you
like lots of improvisation and patchworks then
another kind of languages might be appropriate.
If you are "lazy" and dislike repetitive and boring
work, then again, you should choose language
that doesn't force you to do such a work.
If you choose Eiffel or Python you will get
elegance, consistency and avoidance of boring
and potentially hazardous work.
On the other hand, if you are prepared for
lots of frustration, boring and repetitive work,
than choose C or C++.
For example, in C++ you have to take care about all the memory
that you dynamically allocate for your objects.
You have to deallocate all this memory by yourself.
Other object oriented languages implement garbage
collector that takes care of unused objects.
C++ is a language that wasn't created from scratch.
It attempts to combine two completely different
paradigms: one of a low-level C language (a kind of
portable assembly language), with object oriented
paradigm. This cannot be done successfully. C++
is not a pure object oriented language, which means
it really doesn't give you the whole power of
object-oriented programming. It gives you a rather small
part of it, at best.
I like Python because it is interactive, and it is certainly
a very well-designed language. I think it is very suitable
for a first language. There are also a lot of things
I don't like so much in Python. In certain aspects
Eiffel gives you much more flexibility. Eiffel gives you much
cleaner and more powerful object-oriented programming
model. However, there are also a lot of things where
I like the Python way more than Eiffel way.
I would suggest you to try both. You can download
ISE Eiffel at www.eiffel.com . A free version is about
50 Mb. I am not sure for Mac, but Visual Eiffel has
a version for Mac. Eiffel environments give you certain
important features that cannot be easily found elsewhere.
Also, compared with Python, the free ISE Eiffel compiler
comes with a full featured, professional debugger, and this
is something I miss in Python.
Eiffel has very clean and understandable syntax, and this
is why it is used on many universities in introductory
programming courses.
Regards,
Hrvoje Nezic
Laura Creighton
C and C++ and BASIC are far from ideal languages to learn programming
despite the fact that many people did learn C or BASIC as their first
programming language. Whatever language you learn first will give you
some habits which will last a lifetime, and will form the basic of
your own mental conception of 'what programming is like'. This is a
good thing, and makes learning the next computer language a lot
easier, but it means that you get bad habits in with the good. You
have to unlearn them later. Now, you can write sloppy programs that
reflect sloppy thinking, and unbarably cute programs that are full of
dirty tricks in any language once you learn the language well enough,
but C and Basic are set up so that the dirty way to do things is often
the only way to do things, the easiest way to do things, the most
common way to do things, or the first way you will think of. Thus you
learn an incredible amount of bad habits if you begin learning to
program in C or BASIC. (If you get this far. C and C++ are also
both harder, and less fun to learn. So many people start and give up).
Eventually, you learn enough, and see enough good code, to understand
why it is that your code is poor, and then, if you actually want to
become better you take major steps to change your thinking, your way
of coding, and sometimes your way of life. This is hard. First of
all, changing any habit is hard, but writing code is all about the
power to think things, and the power to do things, which means that
writing code ties directly into your ego. This means that actually
deciding that you write poor code feels very much like deciding that
you are a bad person, even though this is not the case. Thus many
people never change the bad habits they acquired when they were first
learning to program. They remain poor programmers forever. And many
of them console themselves at night with the thoughts that 'most
people write code like this' and 'it is good enough to get the job
done' and even 'I am making a significant amount of money doing this,
so it can't be that bad'. And they are correct in this. Compared to
the people who cannot program at all, they aren't 'that bad'. The
problem is that they _are_ 'that bad' compared to what they _could_ be.
Now, the people who write computer languages, which are, after all,
just another computer program, have thought long and hard about this,
and many of them have tried to come up with a language which is easy
to learn, and which does not teach you many bad habits, and which, not
coincidentally is good for teaching computer science in. Scheme is
one result. Haskell is another. Pascal was an earlier attempt, but
we have invented something called Object Oriented Programming since
that time, so I wouldn't recommend it now. The others are great
first programming languages.
But there is a problem. None of these languages are heavily used in
industry for anything, because while they are great to learn computer
science with, they aren't so great to do anything else with. Python
is different, in that it was designed to be a good programming
language to learn as well as one that you can do useful work with.
Smalltalk was designed with similar goals. As a result, people are
getting useful work done in both languages.
-----
Which you decide to learn depends more on you. If your primary reason
to learn a programming language is 'to impress the university of my
heart's desire', then you need to research what that university desires.
Hint -- MIT is the home of scheme. Lots of universities turn up their
noses at languages you can do useful work in, Haskell is a really good
choice for impressing such places.
If, on the other hand, you want to learn a language in order to leave
school as soon as possible and start earning a living, because you already
have had about as much school as you can stand for a while, then I
would recommend java. Of the commercially successful languages, it
will ruin you the least, in my opinion. Still stay away from C or C++
until you have learned some other language first.
But given that you are in such a hurry and believe that you are running
out of time, I will hazard a guess and propose that you are more of
an artist or an engineer than a mathematician or a scientist, and that
a burning desire to go out and build, create something is what is
motivating you. You woke up one morning, and thought, 'Holy Smokes,
I have all this code to write to build this <cool idea I just had>,
and I don't even know how to program yet!'
If so, then, 100% I recommend that you learn Python no matter what
your teachers or anybody else says. Because what they aren't telling
you, perhaps because they do not know themselves, is that how quickly
you can develop an application from 'i had a cool idea' to 'come see
it; it works a bit now' to 'everybody come see; it works great'
depends on what language you use. And Python is the absolute best at
developing things that take more than a hour to do, of all the
languages I have ever seen, period. It is much, much, much faster
than C or C++ to develop in. This is why experienced, expert C++
programmers learn Python -- they want to get more accomplished in the
same amount of time.
Could you do me a favour and tell me why it is that your teachers
recommended against you learning Python? If it is simply that they
have never heard of it, that is one thing. One of my goals in life
is to make Python widely accepted as a first programming language
among people like your teachers. Clearly, I have more work to do,
but I don't know where I should start until I understand why they
discouraged you in the first place. Did they have any specific reasons
why they thought Python was a bad choice?
Good luck to you, whatever you decide. If you decide on Python, check
out http://www.python.org/doc/Newbies.html and
http://www.python.org/psa/MailingLists.html#tutor
Have fun, and, if you decide to go with C or C++ anyway, get bogged down,
and start thinking -- 'maybe programming isn't for me', do remember that
it is quite possible that what your are experiencing is 'maybe C or
C++ wasn't a good first programming language for me' and don't give up
on programming until you have tried another one.
best of luck,
Laura Creighton
Roy Smith
> Hello, everyone, I am a 9th grade student, who is very interested in learning
> programming. I realize I waited too long to begin, as many have started in
> earlier grades, but I am determined to learn something. But that is where it
> stops. I have no idea what programming language to learn.
You say your teachers have tried to talk you out of learning Python?
Well, Mark Twain is reputed to have said, "I have never let my schooling
interfere with my education". You should take this to heart!
I think Python is an excellent first programming language for somebody
in the 9th grade. It is relatively simple to learn, and powerful enough
to keep you doing useful things for a long time. It will also introduce
you to many modern programming concepts which you'll find in other
languages. I do a lot of production programming in Python.
I wouldn't bother with BASIC at all, but either C or C++ might be good
second langugaes.
Of course, you do realize that it's going to be difficult to get an
unbiased opinion in this group; the people who hang out here are all
Pythonistas already. You might want to ask the exact same question in
some other language groups and see what answers you get. Undoubtedly,
you'll get different opinions, and then you'll be faced with the problem
of looking at all the conflicting data and making your own decision.
This too is a part of real life.
Roy Smith
> Chewdip20 fed this fish to the penguins on Sunday 29 December 2002
> 08:17 pm:
>
> > Oh, and as a follow up to that, you should probably know I use a Mac,
> > so take that into consideration.
> >
> Well, that cuts into things (unless you have room to install a
> PowerPC [it is that, at least?] version of Mandrake Linux).
You hardly need Linux to learn programming on a Mac. Python runs on the
classic MacOS versions, and if you're willing to spend a little money,
you can get commercial C, C++, Java, etc. Metroworks Codewarrior has a
"learning edition" which is only about $100 or so.
If you're running OS-X, you get (or can install via GNU) support for C,
C++, Java, and even Fortran and ADA for free.
Cameron Laird
Laura Creighton <l...@strakt.com> wrote:
>
>C and C++ and BASIC are far from ideal languages to learn programming
>despite the fact that many people did learn C or BASIC as their first
>programming language. Whatever language you learn first will give you
.
.
It surprises me that folks have answered so temperately.
I'll summarize my sentiment: C++ is child abuse.
In the US, certain standardized examinations of
"programming knowledge" aimed at high-school graduates
are expressed in C++. I consider this an intellectual
outrage. I like C++, was once expert in it, and still
more than competent; to inflict it on beginners is an
egregious mistake, though.
C++ is a poor vehicle for communicating concepts, in
comparison with Python, ML, Eiffel, or Scheme, say,
and it's undeniably far harder to learn than C, let
alone Python, Smalltalk, ...
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
DP
especially in terms of clarity of code, and my experience suggests it'll be
quick to learn. Available on Mac too. Good docs & support, not as expansive
as Python, but since you only want to learn, it's worth considering.
An interpreted language is definitely a huge learning plus. And the focus
ought to be on learning, with less time spent on semantics, more on
concepts.
And then there's OCaml. see http://caml.inria.fr/FAQ/general-eng.html. I've
heard good things, but don't really know it. I didn't pursue it because I
found the semantics "different" from anything else I have used. But you
probably don't suffer from this baggage. And I think that is indeed rare for
anyone on this list.
Also, if you're more of a math student than Comp Sci, look into R. It's a
beauty.
Anyway, this thread has more suggestions than you probably have time.
All the best.
"Chewdip20" <chew...@aol.com> wrote in message
news:20021229230751...@mb-bj.aol.com...
Cameron Laird
DP <penne...@excite.com> wrote:
.
.
.
>Also, if you're more of a math student than Comp Sci, look into R. It's a
>beauty.
.
.
"R is a language and environment for statistical computing and graphics."
<URL: http://www.r-project.org/about.html >
<URL: http://wiki.tcl.tk/R >
Roy Smith
> C++ is a poor vehicle for communicating concepts, in
> comparison with Python, ML, Eiffel, or Scheme, say,
> and it's undeniably far harder to learn than C, let
> alone Python, Smalltalk, ...
I'll agree with that 100%.
I know (or have known) a bunch of languages; Basic, Fortran, C,
various assemblers, lisp, Python, TCL, Perl, Hypercard, NewtonTalk (or
whatever it was that you programmed the Apple Newton in), SQL,
assorted Unix shells, postscript, HP-41-ish, and probably a few more I
can't think of now. I like some of them, and dislike others, but I've
never seen one which was as complex to learn as C++.
I've made a few attempts to teach myself C++ over the years, all of
them have been failures. I'm currently in the middle of a much more
serious attempt, this time with the advantage of having a couple of
experts around to pester with questions. I think I'm finally getting
it now, but progress is horribly slow.
The problem is, I never feel like I'm programing the *problem*, I
always feel like I'm programming the *language*. I design a fairly
simple class which would take me an hour to write and debug in Python
and find myself spending days fighting with syntactical complexities
and struggling to figure out bizarre error messages. Special cases
and surprises abound, which makes it very difficult to generalize
anything I've already learned. Here's one that bit me just the other
day.
Call a function with 2 args: function (arg1, arg2);
Call a function with no args: function ();
Define an object with 2 initializers: myClass o (init1, init2);
Now, try to generalize that to defining an object with no
initializers. Obviously, I wrote: myClass o();
Well, heck, it turns out what I really did was to declare a function
called o which take no arguments and returns an object of type
myClass. I didn't get an error message until the first time I tried
to use the object, and then the message was so mind-bogglingly bizarre
I had no clue what I did wrong.
Bletch.
Please don't try and learn C++ as a first language. Even if it
doesn't completely turn you off to programming, it'll poison your mind
as to how things "should be".
There is one and only one reason I'm forcing myself to learn C++ now,
and that's because in the current job market, it seems like you can't
even get an interview if you don't have it or Java on your resume, and
this seems like the lesser of two evils.
Martin Christensen
Hash: SHA1
>>>>> "Cameron" == Cameron Laird <cla...@lairds.com> writes:
Cameron> C++ is a poor vehicle for communicating concepts, in
Cameron> comparison with Python, ML, Eiffel, or Scheme, say, and it's
Cameron> undeniably far harder to learn than C, let alone Python,
Cameron> Smalltalk, ...
I agree with you, but it does need some rationalisation.
C and C++ are rather heavy on the bookkeeping side. In Danish (I don't
know about other human languages) the term 'pointer gymnastics' often
occurs along side mention of these languages; when dealing with
variables you need to constantly switch between referencing,
dereferencing and dealing with actual values, which requires a mental
effort that's better spent on expressing your ideas in code, if you
ask me. While C is a small and elegant language with very few
constructs to learn, C++ is anything but small and elegant, yet the
things which make it big and bloated are also the things that make it
useful. Python and several other languages have the practicality of
C++ while staying small, simple and elegant.
C and C++ will teach you about how the machine works on a basic level,
but personally I believe that these details are less important than
understanding the problem solving techniques on a more abstract level
that are necessary to becoming a good programmer. When you know how to
solve your problem you can benefit from knowing how the machine works
on a lower level so that you can solve your problem in a more
efficient manner.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj4QY7sACgkQYu1fMmOQldUr9QCgoUfxaGV9ZhnahbOcz6qeX9ZI
HF0AoOakDr9wJi255b3F+ijz0uP5mtB5
=h2se
-----END PGP SIGNATURE-----
Nick Vargish
have been very good. One thing that has a lot of bearing on what
language is "best" for you is your motivation for picking up
programming. You didn't make that quite clear in your post.
If you want to learn to program because you're considering it as a
career, I think Python might be the wrong choice for you (at this
stage). It will teach you a lot about "how to program", but it is not
a language with a lot of employment opportunities -- trust me, I just
spent four months on the market, and only by luck do I get to use
Python in the office[*]. Getting used to Python might also mean that
you will be very frustrated when you have to program C++, Java, or
Visual Basic to make your living.
So, if you are getting into this for a career, I think you should
start with C, which can be learned in a couple of weeks. Then move to
C++ once you have a grasp of memory handling in C, because that's a
complicated and dangerous aspect of both C/C++, and the most critical
to learn if you're going to be a professional. There seems to be a
lot of call for Java programmers these days, and as much as I dislike
the language, it is pretty easy to pick up in a few weeks.
If you are interested in programming as an intellectual excercise, I
think Python is a terrific way to go. It is an excellent procedural-
style language with a very pleasant object model. You can start with
the basics of "traditional" process-oriented programming, and easily
move into object oriented and data-driven programming with Python.
If you have a few tasks you want to solve by programming them, Python
is also a great language. It has a command-line interpreter, so you
can easily experiment with various approaches to accomplishing your
goals.
Personally, I think the best reason to program is because it's fun and
rewarding. Python is the most fun programming language I've ever used,
and that's why I do all my personal projects in Python. I
occassionally find myself chuckling to myself while I code, because it
all fits together so beautifully. On the other hand, I'm the kind of
computer language geek who taught himself Scheme, Smalltalk,
assembler, and several others just for the fun of it.
Nick
[*] At my new job the boss is looking to rewrite some decrepit and
ancient C programs in "something else." He's willing to let me
make a case for Python by demonstating it can Do The Job. If I
fail, we will be working in Java or Something Worse (Visual
Basic)... As you can see, the stakes have rarely been higher.
--
#include<stdio.h> /* SigMask 0.3 (sig.c) 19990429 PUBLIC DOMAIN "Compile Me" */
int main(c,v)char *v;{return !c?putchar(*v-1)&&main(0,v+ /* Tweaks welcomed. */
1):main(0,"Ojdl!Wbshjti!=obwAqbusjpu/ofu?\v\1");} /* build: cc -o sig sig.c */
Michael Prager
>C and C++ will teach you about how the machine works on a basic level,
>but personally I believe that these details are less important than
>understanding the problem solving techniques on a more abstract level
>that are necessary to becoming a good programmer.
I completely agree with this. There is no reason for a beginner
to start with something like C or C++. Python would be far
better, as it puts more emphasis on the problem and less on the
silly machine mechanics than C or C++. Even modern Fortran
would be better than C, if the poster is mainly interested in
numerical problems.
--
Mike Prager
NOAA, Beaufort, NC
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
Martin Christensen
Hash: SHA1
>>>>> "Nick" == Nick Vargish <n...@adams.patriot.net> writes:
Nick> So, if you are getting into this for a career, I think you
Nick> should start with C, which can be learned in a couple of
Nick> weeks. Then move to C++ once you have a grasp of memory handling
Nick> in C, because that's a complicated and dangerous aspect of both
Nick> C/C++, and the most critical to learn if you're going to be a
Nick> professional.
I don't agree with you. In essence you're suggestion that he start
learning _languages_, but what he really needs, especially considering
that he's a 9th grader, is to learn _programming_ as a mental
discipline and technique. It might be the case that currently
(historically) C and C++ are very popular languages for getting work
done, more out of convention than for any practical reasons, I
suspect, and as such they're useful languages. If my experience counts
for anything, those who have C(++) (and for different reasons also
PHP, VisualBasic etc.) for a first language far more often turn out
being just coders as opposed to real programmers. By this I mean that
'just coders' have all the bad habits that come from the union of
short-sightedness and pragmatism ("wow, I'm coding, I'm so 1337!"),
whereas 'real programmers' solve problems in their heads before they
do so in code, at least partially.
Python and other high-level general-purpose languages better allow
novices to focus on the actual problem solving, where in C(++) they
tend to worry more about how to initialise an array correctly, or mess
around with semi-incomprehensible semantics. C++ was my second
language after BASIC, and I think that this was a major contributing
factor to why I didn't 'get' programming until long after I'd learned
how to code: when every line of code is a struggle, near-sightedness
is an inevitability.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj4Qf9cACgkQYu1fMmOQldWDYACgujnf83LVZ0byWaYNG/gD70lP
sJQAoLRekPddqaa0rerT15AMVZH/IaEl
=ZoPX
-----END PGP SIGNATURE-----
William Park
> Perhaps I missed it, but did anyone suggest Ruby? Some similarity to Python,
It's closer to Perl.
Nick Vargish
> I don't agree with you. In essence you're suggestion that he start
> learning _languages_, but what he really needs, especially considering
> that he's a 9th grader, is to learn _programming_ as a mental
> discipline and technique.
Maybe I was drawing too strongly on my own background; when I was in
high school we were taught Pascal, because that was considered to be a
good language for teaching the "mental discipline" and "techniques" of
the day. I was already writing games for my Fujitsu Micro-8 and
sharing them with a large audience, so Pascal was a cakewalk... But a
lot of my classmates really struggled with it, as you did with C++.
I'm just not convinced that _any_ programming language can really
teach the discipline of solving the problem before a line of code is
written. Maybe a class in geometry (proofs) would be a good start.
For someone who's never written a program before, _any_ language is
going to be confusing -- even Python has a number of syntactic
"tricks" that have to be mastered, such as '()' for tuples, '[]' for
lists, and '{}' for dictionaries. Then the novice will want to know
why a tuple is distinct from a list...
In my opinion, Scheme is close to a language that teaches the basics
of algorithm design and problem solving with a minimal amount of
syntax. I find it quite lovely to work with, but most people think I'm
insane.
Nick
Martin Christensen
Hash: SHA1
>>>>> "Nick" == Nick Vargish <n...@adams.patriot.net> writes:
Nick> I'm just not convinced that _any_ programming language can
Nick> really teach the discipline of solving the problem before a line
Nick> of code is written.
The language can't teach it in and of itself, but it can help by not
'getting in your way'. Python is one language that at least doesn't
get in my way, and others have reported the same, while C and C++
definitely do, especially the latter. The main difference is on
whether you're free to complete the task you set out to do, or if you
are more tied up in language details.
Nick> In my opinion, Scheme is close to a language that teaches the
Nick> basics of algorithm design and problem solving with a minimal
Nick> amount of syntax. I find it quite lovely to work with, but most
Nick> people think I'm insane.
You could possibly be right. Also Scheme and other functional
languages draw very heavily on the mathematical concept of a function
(input, output and no sideeffects), which might be a benefit, but it
then removes itself from the commonly used recipe metaphor. In Scheme
the execution model is also made entirely explicit and transparent by
the parentheses, which also ought to facilitate better comprehension.
I learnt coding by studying (poor) examples and reading the on-line
help files for MS QBasic back in the day, so I didn't have the benefit
of either metaphor to help me, so I can't say what works and what
doesn't. :-)
At my university they started using ML to teach first-year science
students (broadly, not just computer scientists) programming, and the
results have been good compared to Pascal, which was what was used
before.
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj4QjVAACgkQYu1fMmOQldVAIwCffWQi49CkqU9uoGYzQ8/cuYHK
KoAAn3FCmTV10/ambqWxvMcTFCwRqpxR
=A8zF
-----END PGP SIGNATURE-----
Nick Vargish
> The language can't teach it in and of itself, but it can help by not
> 'getting in your way'.
Okay, that's a good point. C++ certainly doesn't help in this regard,
nor does Java for that matter...
Ken Starks
<knightsofspam...@gvdnet.dk> quotes Nick:
>Nick> I'm just not convinced that _any_ programming language can
>Nick> really teach the discipline of solving the problem before a line
>Nick> of code is written.
I once ran a computer club for ten and eleven year-olds. One day, after
a boy had been 'learning programming' (his phrase) for 50 minutes, a
visitor asked him what language he used.
Looking sheepishly at me, he replied, "....er, pseudocode ???".
A good guess, I thought. I was quite proud of it in a way.
I deliberately used to emphasise programming, and de-emphasise coding.
The standard aimed at was similar to Guido's 'tutorial introduction' to
python, but I didn't know python in those days. Children of that age
commonly reach a ceiling in their programming skills because their
Mathematical development. That is just one reason why breadth is
preferable to depth.
In succeeding terms, I used Forth, Basic, and Prolog, selected for their
contrast and for different favoured Data-structures.
I also recommended pseudocode and other proper programming
disciplines such as a 'specification' and 'test suite' when
designing a spreadsheet.
--
Ken Starks
Grant Edwards
> Since C++ was a version of C with an Object-Oriented mode
> tacked onto it, it is likely more difficult than straight C to
> learn -- but OTOH, one doesn't have to unlearn some C idioms if
> transitioning from C to C++.
But, it can take years to figure out _which_ idioms you can keep
and which ones should be unlearned...
--
Grant Edwards grante Yow! Yow! Are we wet yet?
at
visi.com
Grant Edwards
> If you want to learn to program because you're considering it as a
> career, I think Python might be the wrong choice for you (at this
> stage). It will teach you a lot about "how to program", but it is not
> a language with a lot of employment opportunities -- trust me,
It may be true that there aren't a lot of job openings
involving Python, but a "first language" should be chosen for
it's usefulness in learning concepts. No professional I've
ever met knows only a single language. Most know dozens.
Learning Python first isn't going to prevent somebody from
learning Java, C, Pascal, or whatever. IMO, it will help them.
> So, if you are getting into this for a career, I think you
> should start with C, which can be learned in a couple of weeks.
I must disagree. The more you're considering programming as a
career, the more important it is to learn basic programming
concepts well. C is horrible for that. C++ is worse.
Learn Python first, then learn Scheme, Prolog, PDP-11
assembler, Fortran, Java, C. I suppose you can through in C++
if required...
--
Grant Edwards grante Yow! With this weapon
at I can expose fictional
visi.com characters and bring about
sweeping reforms!!
Karl A. Krueger
> Maybe I was drawing too strongly on my own background; when I was in
> high school we were taught Pascal, because that was considered to be a
> good language for teaching the "mental discipline" and "techniques" of
> the day. I was already writing games for my Fujitsu Micro-8 and
> sharing them with a large audience, so Pascal was a cakewalk... But a
> lot of my classmates really struggled with it, as you did with C++.
I'd played with BASIC and Forth before high school age, but had Scheme
and Pascal in classes around that age. At the time I took Scheme, the
summer program I was in was teaching intro CS in both Pascal and Scheme
sections, with the same final project: to write an interpreter for a
simple arithmetic language.
As I recall, all of the Scheme students completed the project, with code
listings in the range of 3 to 5 pages. Several of the Pascal class did
not complete it, and those who did had listings closer to 8-12 pages. I
think that was enough to convince me that Pascal is not the greatest
language for learning. :)
When I had Pascal the following year, the only real trouble was the
teacher's very sneaky trick questions, intended to teach careful
programming in a language that doesn't lend itself to same ...
> I'm just not convinced that _any_ programming language can really
> teach the discipline of solving the problem before a line of code is
> written. Maybe a class in geometry (proofs) would be a good start.
Boolean logic isn't in the usual American high-school math sequence,
which is a shame, but it's a better introduction to proofs than geometry
is, IMHO, since it is simpler: the student doesn't have to learn as
complex of an axiom system at the same time that s/he is learning how to
do a proof.
Our intro CS classes required that programs be written on paper first,
and checked over, before being entered into a computer. I understand
that's considered "old-fashioned", but it does ensure that students do
not learn the mistake that "if it compiles, it must be right".
> For someone who's never written a program before, _any_ language is
> going to be confusing -- even Python has a number of syntactic
> "tricks" that have to be mastered, such as '()' for tuples, '[]' for
> lists, and '{}' for dictionaries. Then the novice will want to know
> why a tuple is distinct from a list...
"A tuple is like an ordered pair in geometry. You can have a lot of
different tuples, but you can't change one once you have it, just like
you can't change the meaning of the number 5. 5 is always 5, and (2,3)
is always (2,3). A list is different -- it's like a shopping list, you
can add items to it and take them off, or change them."
I think the distinction between variables and values might be overall
more fundamental and more tricky for new programmers. Python is a good
place to learn it, though -- as is Scheme, and as isn't C. ("If &a is
the address of a, is that the address of the variable? Is that the
variable? Is that the address of the value?")
> In my opinion, Scheme is close to a language that teaches the basics
> of algorithm design and problem solving with a minimal amount of
> syntax. I find it quite lovely to work with, but most people think I'm
> insane.
Scheme's great for expressing algorithms that aren't about anything but
themselves. It ain't so great for expressing algorithms that are about
other things out in the world or on the network, which is what Python is
good for. :)
--
Karl A. Krueger <kkru...@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Nick Vargish
> I'd played with BASIC and Forth before high school age, but had Scheme
> and Pascal in classes around that age.
I wish the CS teacher in my high school had introduced us to
Scheme. That would have been great. As it was, I got so bored with
Pascal that I taught myself FORTH. For a month I submitted all my
class exercises in FORTH, until he begged me to stop... "I can see
that your programs work, but I can't figure out _how_ they work."
So I talked him into letting me do the rest of the year in C, which
was fun and prevented the rest of the class from "looking over my
shoulder" when it came to in-class assignments.
> When I had Pascal the following year, the only real trouble was the
> teacher's very sneaky trick questions, intended to teach careful
> programming in a language that doesn't lend itself to same ...
I got a 99% on the final, because apparently Wile E. Coyote did not
invent the Pascal programming language. :^)
> Boolean logic isn't in the usual American high-school math sequence,
> which is a shame, but it's a better introduction to proofs than geometry
> is, IMHO, since it is simpler:
Good point. I didn't get boolean logic until I started taking
Philosophy classes in college. That does say something sad about the
curriculum of my high school, I guess (Singapore American School,
early-mid 80s).
> "A tuple is like an ordered pair in geometry." ...
Thanks, I knew that. :^)
I'm taking a lot of heat here for my "pragmatic" advice. In my
defense, for some reason I thought the original poster was in 12th
grade, not 9th. So let me change my original answer:
"Learn Python, but it will spoil you for anything else you might be
forced to use in the future..."
Robin Munn
> DP <penne...@excite.com> wrote:
>> Perhaps I missed it, but did anyone suggest Ruby? Some similarity to Python,
>
> It's closer to Perl.
Now, now -- most of the other posters were keeping their language
reasonably civil, and you have to go and say something like that! :-)
--
Robin Munn <rm...@pobox.com>
http://www.rmunn.com/
PGP key ID: 0x6AFB6838 50FF 2478 CFFB 081A 8338 54F7 845D ACFD 6AFB 6838
Karl A. Krueger
> "Karl A. Krueger" <kkru...@example.edu> writes:
>> I'd played with BASIC and Forth before high school age, but had Scheme
>> and Pascal in classes around that age.
> I wish the CS teacher in my high school had introduced us to
> Scheme. That would have been great. As it was, I got so bored with
> Pascal that I taught myself FORTH. For a month I submitted all my
> class exercises in FORTH, until he begged me to stop... "I can see
> that your programs work, but I can't figure out _how_ they work."
It can be a little confusing. I don't remember a word of it.
Forth and Scheme are interesting languages to compare, though, because
they are both "low syntax" languages, but in -completely- different
ways. I think of Python as being a "medium syntax" language -- it's not
trivial, but it doesn't go out of its way to make you jump through hoops
(like Pascal) or to be clever (like Perl).
>> When I had Pascal the following year, the only real trouble was the
>> teacher's very sneaky trick questions, intended to teach careful
>> programming in a language that doesn't lend itself to same ...
> I got a 99% on the final, because apparently Wile E. Coyote did not
> invent the Pascal programming language. :^)
I think that was Wirth E. Coyote actually.
My first high school CS instructor was a great guy, albeit a very tricky
one -- he wanted to keep everyone on their toes. He was mostly a math
teacher, actually, and has a book out on teaching math (with a little CS
thrown in):
http://www.maa.org/pubs/books/tyb.html
He would invariably put in every problem set or test at least one trick
question, involving tricky function calls (okay, which parameters were
"var" this time?), variable scope ("crap, how many variables called "X"
does this program have?) and so forth -- the sort of things that one
hopes -never- to run into in reading someone else's code!
>> Boolean logic isn't in the usual American high-school math sequence,
>> which is a shame, but it's a better introduction to proofs than geometry
>> is, IMHO, since it is simpler:
> Good point. I didn't get boolean logic until I started taking
> Philosophy classes in college. That does say something sad about the
> curriculum of my high school, I guess (Singapore American School,
> early-mid 80s).
It's one of my pet peeves about the education system. Boolean algebra
is a simple and useful thing that connects language and rhetoric to math
and computing ... and it is not taught to students who are supposed to
be learning language, rhetoric, math, or (often) computing. I'm very
glad that I got it in an early CS course.
>> "A tuple is like an ordered pair in geometry." ...
> Thanks, I knew that. :^)
Sure, but the high schooler mightn't. The quotes were "this is how to
explain it" ...
> "Learn Python, but it will spoil you for anything else you might be
> forced to use in the future..."
It makes a lot more sense than teaching a B&D language like Pascal or a
mess like C++ or Java.
Martin Christensen
Hash: SHA1
>>>>> "Dennis" == Dennis Lee Bieber <wlf...@ix.netcom.com> writes:
>> It makes a lot more sense than teaching a B&D language like Pascal
>> or a mess like C++ or Java.
Dennis> Does that mean PERL is an S&M language? <G>
Yes, which is why so many people write Perl code in vi. :-)
All-hail-Emacs,-now-let-the-flames-roar-high-ly yours,
Martin
- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>
iEYEARECAAYFAj4RCzcACgkQYu1fMmOQldU+nACgidsv+/pW84ry6pt0E1xc8xJY
sTEAnjebbVpGNFsARG9GWCXznSlnCl5V
=HGBE
-----END PGP SIGNATURE-----
Kyler Laird
>Learn Python first, then learn Scheme, Prolog, PDP-11
>assembler, Fortran, Java, C. I suppose you can through in C++
>if required...
Would you like to argue that order? I think assembler should be taught
right after learning about gates. Get a taste of it and then jump right
to Python.
I'm even hoping to teach a class that way...
--kyler
Grant Edwards
> gra...@visi.com (Grant Edwards) writes:
>
>>Learn Python first, then learn Scheme, Prolog, PDP-11 assembler, Fortran,
>>Java, C. I suppose you can through in C++ if required...
>
> Would you like to argue that order?
There probably should be a purely functional language in there too. And
some Smalltalk.
Nope, except for C being towards the end and C++ being last. I haven't
learned C++ yet[*], and I've been programming for 30+ years and have
probably forgten at least a dozen languages by now. It's taken a little
effort to avoid C++, but I think it's been worth it. :)
> I think assembler should be taught right after learning about gates. Get a
> taste of it and then jump right to Python.
That would be an interesting approach. I think everybody should learn
PDP-11 assembly and look at the instruction set at the machine level. It
was a beautiful design.
> I'm even hoping to teach a class that way...
I wonder if you could find a PDP-11 simulator and assembler somewhere...
[*] I've not learned enough C++ to use it, but I have learned enough to try
to avoid it.
--
Grant Edwards grante Yow! Did I SELL OUT yet??
at
visi.com
Simon Wittber (Maptek)
>>Fortran, Java, C. I suppose you can through in C++ if required...
>
right after learning about gates. Get a taste of it and then jump
>right to Python.
>
I agree. I personally learned logic gates, then assembly simultaneously
with C at TAFE (Trade college in Australia). To me this was a killer
combination. I found my comp sci uni degree rather easy, and I believe
I came out a much better programmer because of my early low-level
programming education.
John Burgoon
Let's say I want to "learn programming" in your ideal five or six languages.
What are the first five (ten? fifteen?) projects that you would have me do?
Example: Project One is HelloWorld.
And should I do those projects in one language, then proceed to the next, or
should I do each project in each of five or six languages before moving to
the next project?
Yu Wang
Nick Vargish wrote:
>If you want to learn to program because you're considering it as a
>career, I think Python might be the wrong choice for you (at this
>stage). It will teach you a lot about "how to program", but it is not
>a language with a lot of employment opportunities -- trust me, I just
>spent four months on the market, and only by luck do I get to use
>Python in the office[*]. Getting used to Python might also mean that
>you will be very frustrated when you have to program C++, Java, or
>Visual Basic to make your living.
>
Yeah. I'm totally agreed with that.
For commercial usage, python is far from a "perfect" language. You'll
have to
make a choice among C/C++ , java, or something else. But it will be the
last one
to choose python.
Nevertheless, I've once encouraged by one article saying "using python as a
prototype language, and then translate inot C/C++, or whatever". In that
paper,
I'm astonished to discover the author is quite confort at python as to
just keep
the codes as they are---in python.
>
>If you have a few tasks you want to solve by programming them, Python
>is also a great language. It has a command-line interpreter, so you
>can easily experiment with various approaches to accomplishing your
>goals.
>
>Personally, I think the best reason to program is because it's fun and
>rewarding. Python is the most fun programming language I've ever used,
>and that's why I do all my personal projects in Python. I
>occassionally find myself chuckling to myself while I code, because it
>all fits together so beautifully. On the other hand, I'm the kind of
>computer language geek who taught himself Scheme, Smalltalk,
>assembler, and several others just for the fun of it.
>
>
It's interesting to find people like to use python as a "personal
weapon" to handle
boring tasks. So do I:)
The interprter characteristic of python also make programming in python a
game of imagination.
Think about you can test your idea in dozens of ways, in dozens of seconds.
And, as python is simple to learn, you can always learn python and
C/C++, or
whatever all. One at a time.
--
Best Regards!
Yu Wang
Cameron Laird
Grant Edwards <gra...@visi.com> wrote:
.
.
.
>I wonder if you could find a PDP-11 simulator and assembler somewhere...
.
.
Oh, my, yes. The folks at alt.sys.pdp11 and vmsnet.pdp-11
have multiple ones they seem to favor. I think some are
even publicly accessible ...
Grant Edwards
> OK, I'll throw out THIS question...
>
> Let's say I want to "learn programming" in your ideal five or
> six languages. What are the first five (ten? fifteen?) projects
> that you would have me do? Example: Project One is HelloWorld.
Ideally, the projects should be things in which you're
interested and want to have done. For example, if you're a
golfer, you may want to write a program to track your handicap.
Pick something reasonable, don't try to write a 3-D golf
simulator as your first program.
> And should I do those projects in one language, then proceed to
> the next, or should I do each project in each of five or six
> languages before moving to the next project?
It's often interesting to write the same program in two
different languages, but I don't know that it's required.
--
Grant Edwards grante Yow! Ha ha Ha ha Ha ha
at Ha Ha Ha Ha -- When will I
visi.com EVER stop HAVING FUN?!!
Bengt Richter
>In article <v129kf5...@corp.supernews.com>, John Burgoon wrote:
>
>> OK, I'll throw out THIS question...
>>
>> Let's say I want to "learn programming" in your ideal five or
>> six languages. What are the first five (ten? fifteen?) projects
>> that you would have me do? Example: Project One is HelloWorld.
>
>Ideally, the projects should be things in which you're
>interested and want to have done. For example, if you're a
>golfer, you may want to write a program to track your handicap.
>Pick something reasonable, don't try to write a 3-D golf
>simulator as your first program.
>
>> And should I do those projects in one language, then proceed to
>> the next, or should I do each project in each of five or six
>> languages before moving to the next project?
>
>It's often interesting to write the same program in two
>different languages, but I don't know that it's required.
>
IMO it's more important to do one version based on objects than
to duplicate procedural habits of thought in several languages.
I'm wondering if programming newbies would benefit from doing
the object-oriented version first. I suspect so. And Python makes
it easy enough.
Python is fine for doing it both ways (with meta stuff as bonus).
Regards,
Bengt Richter
je...@compy.attbi.com
> IMO it's more important to do one version based on objects than
> to duplicate procedural habits of thought in several languages.
> I'm wondering if programming newbies would benefit from doing
> the object-oriented version first. I suspect so. And Python makes
> it easy enough.
>
> Python is fine for doing it both ways (with meta stuff as bonus).
It took me a while to realize this, but I now think that my absolute
favorite thing about Python is how easy it makes it to do things *the
right way*, the first time. Often, it's even *easier* to do it "the right
way" then to kludge your way through the wrong way even once.
An example of what I mean from C++: Before the standard string libraries
were available enough to count on them being there, the tempation to just
write "char something[80]", despite the well-known dangers of
constant-sized buffers on the stack and the difficulty of secure
programming with them even in non-hostile environments, was often
overwhelmning. One would generally write code with constant-sized buffers
and frequently and dangerously just ignore the limits.
Once string libraries became reliably available, one can just write
"string something;", and suddenly "the right way" (more or less) is
*easier* then kludging along in C-style string manipulations. I actually
witnessed this transition in my local Uni's C++ cirriculum as a teaching
assistant and it made my life easier as a teaching assistent as well as
the student's lives easier.
In Python, you get a two-line effective Singleton pattern (Borg). Proxies
are easy. In another thread I posted a proxy-alike that when you need, you
need, and while I'm sure you could pull equivalent tricks in some other
languages, I bet none will be easier then Python. It's easier to write an
iterator-generator and a seperate function to do whatever it is you want
to do with the iterator then to merge data manipulation and traversal into
one function, as people so often do in other languages. (One of my recent
projects at work was just such a seperation, in Perl. The lack of
generators made the iterator's 'next' method very tricky to write, and probably
impossible for anyone else to modify in the future, even with my extensive
commenting and seperate paper documentation.) Adapters are typically so
easy it's scary. Queue makes it easier to do threading correctly then muck
about with semaphores in many cases. Metaclasses give one a shot at doing
things when the class system isn't enough. All bound together with a
simple and clean syntax that makes these features easy, not extremely
esoteric.
In the larger programs I write, I am frequently faced with the question,
"Should I kludge this feature in, or do a more general and theoretically
correct meta-solution and include the feature as a special case?" Python
is the only language I've used where the second option is frequently and
reliably actually easier then the first, *even if you only intend to build
that one feature on top of the more correct solution*.
To connect back to the original posting... it's a shame when people are
merely helped in their procedural ways without at least showing them the
better ways. Some people will program in
Python-that-might-as-well-be-COBOL, and perhaps the tutorials should start
with procedural to ease the learning curve, but they should at least be
exposed.
Erik Max Francis
> Yeah. I'm totally agreed with that.
> For commercial usage, python is far from a "perfect" language. You'll
> have to
> make a choice among C/C++ , java, or something else. But it will be
> the
> last one
> to choose python.
If Java were to be acceptable for commercial usage, what would prevent
Python from it?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Did you ever love somebody / Did you ever really care
\__/ Cassandra Wilson
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Erik Max Francis
> Assuming you mean to only learn at the introduction level
> (since
> mastery takes time) I'd suggest: ...
>
> Historical numerical processing: FORTRAN 77 ...
>
> Historical business processing: COBOL
>
> An ALGOL descendent (block structured): Ada
>
> A scripting (interpreted) language: Python (both Ada and Python
> have
> forms of Object Orientation, Fortran 90 introduces modules so may be
> moving toward OO, and some of the newest COBOLs claim to be Object
> Oriented).
>
> A LISP descendent: Common Lisp or Scheme (if you are using EMACS
> you
> may already have a LISP available <G>)
My list for breadth would include C, probably Java instead of C++,
Prolog, Scheme instead of Common Lisp, and perhaps just a touch of
APL/J.
Terry Hancock
> Yu Wang wrote:
>
> > Yeah. I'm totally agreed with that.
> > For commercial usage, python is far from a "perfect" language. You'll
> > have to
> > make a choice among C/C++ , java, or something else. But it will be
> > the
> > last one
> > to choose python.
>
> If Java were to be acceptable for commercial usage, what would prevent
> Python from it?
I think that Yu Wang must mean that Python has limited acceptance in the
commercial job marketplace.
Of course, that's a silly thing to say to a 9th grader -- by the time they
are actually looking for a job, the picture will have changed completely.
Python may be the "only" language for business programming by then (or
completely forgotten). Same for C++ or Java or Perl for that matter.
Actually I'm sure all those languages will still be used by somebody, but
relative popularity is fickle. Just compare the current marketplace with
where it was ten years ago (1993). Remember, that's the year HTTP was first
deployed. Linux was a fledgling and hardly anyone had heard of Python (I
don't actually know when Python was invented). Java was hardly known either.
Perl was around, but not that widely used (because it was the web that made
it insanely popular). I don't think CGI had been invented, and C/C++
dominated the commercial programming marketplace. People who wanted to sound
superior dissed those of us still using Fortran. (So, okay, some things
*haven't* changed, but you get the picture). Time flies, huh?
Cheers,
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
"Some things are too important to be taken seriously"
Jacek Generowicz
> Nick Vargish <n...@adams.patriot.net> wrote:
[snip]
> > FORTH
> I don't remember a word of it.
LOL!
(You didn't put a smiley, but I assume the joke was intentional.)
Kyler Laird
>It's often interesting to write the same program in two
>different languages, but I don't know that it's required.
I was recently a guest teacher for a Fortran class that was
assigned to rewrite their largest programming assignmenet
(a simple calculator) in Python. It was strange to see
Fortran rewritten as Python. (I'm told that the teacher
has a tough time getting the students to write in Fortran
after this exercise.)
One of the best things I noticed a student do was that
since he didn't know how to do something in Python, he
implemented his need (I forget exactly what it was.) using
a piece of Python that he did understand. (Think in terms
of implementing a dictionary as a list.)
While this might seem like a failure to adequately learn
the language, I thought it was great that he was thinking
about how to work around a feature missing in (his
understanding of) a language.
To me, a big part of learning multiple languages is getting
exposure to different ways of thinking. Then you can
implement a solution using whatever language is available.
--kyler
Nick Vargish
> If Java were to be acceptable for commercial usage, what would prevent
> Python from it?
I hate to say it, but "managerial mind-share." Somehow, Java managed
to break into management thought patterns as something trendy, useful,
or widespread. The widespread bit is actually becoming a
self-fulfilling prophecy.
Something that I always find amazing is that there is actually a lot
of resistence to using any open source software in the commercial
world. Java actually earns some respect in those circles _because_ it
is largely the "property" of a single company. I've had a hosting
company tell me that their network could not be source of a problem we
were experiencing, because they used "proprietary and very expensive
software" to configure and monitor it...
What we need for Python to get commercial attention is for some large
companies to start charging real money for development environments,
libraries, and consulting. Then we might see Python take off in the
commercial sector. Also good would be for some proprietary and very
expensive software packages start supplying Python APIs or embedding.
Happy Occidental New Year, everyone!
Cliff Wells
> Erik Max Francis <m...@alcyone.com> writes:
>
> > If Java were to be acceptable for commercial usage, what would prevent
> > Python from it?
>
> I hate to say it, but "managerial mind-share." Somehow, Java managed
> to break into management thought patterns as something trendy, useful,
> or widespread. The widespread bit is actually becoming a
> self-fulfilling prophecy.
It's called marketing. Many (mis)managers read trade journals and
believe what they read. If I believed everything I've read about java
in these journals, I'd be in comp.lang.java right now.
> Something that I always find amazing is that there is actually a lot
> of resistence to using any open source software in the commercial
> world. Java actually earns some respect in those circles _because_ it
> is largely the "property" of a single company. I've had a hosting
> company tell me that their network could not be source of a problem we
> were experiencing, because they used "proprietary and very expensive
> software" to configure and monitor it...
>
> What we need for Python to get commercial attention is for some large
> companies to start charging real money for development environments,
> libraries, and consulting. Then we might see Python take off in the
> commercial sector. Also good would be for some proprietary and very
> expensive software packages start supplying Python APIs or embedding.
Easy solution: tell them you need $800 to buy the Python development
system. Download and install Python, pocket the money, tada: everyone's
happy. They might be even happier if you tell them that they'll have to
fork over licensing fees for every application shipped ;)
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308 (800) 735-0555 x308
Yu Wang
Terry Hancock wrote:
>On Tuesday 31 December 2002 08:21 pm, wrote:
>
>
>>Yu Wang wrote:
>>
>>
>>
>>> Yeah. I'm totally agreed with that.
>>> For commercial usage, python is far from a "perfect" language. You'll
>>> have to
>>> make a choice among C/C++ , java, or something else. But it will be
>>> the
>>> last one
>>> to choose python.
>>>
>>>
>>If Java were to be acceptable for commercial usage, what would prevent
>>Python from it?
>>
>>
>
>I think that Yu Wang must mean that Python has limited acceptance in the
>commercial job marketplace.
>
>Of course, that's a silly thing to say to a 9th grader -- by the time they
>are actually looking for a job, the picture will have changed completely.
>Python may be the "only" language for business programming by then (or
>completely forgotten). Same for C++ or Java or Perl for that matter.
>
>Actually I'm sure all those languages will still be used by somebody, but
>relative popularity is fickle. Just compare the current marketplace with
>where it was ten years ago (1993). Remember, that's the year HTTP was first
>deployed. Linux was a fledgling and hardly anyone had heard of Python (I
>don't actually know when Python was invented). Java was hardly known either.
>Perl was around, but not that widely used (because it was the web that made
>it insanely popular). I don't think CGI had been invented, and C/C++
>dominated the commercial programming marketplace. People who wanted to sound
>superior dissed those of us still using Fortran. (So, okay, some things
>*haven't* changed, but you get the picture). Time flies, huh?
>
>Cheers,
>Terry
>
>--
>Terry Hancock ( hancock at anansispaceworks.com )
>Anansi Spaceworks http://www.anansispaceworks.com
>
>"Some things are too important to be taken seriously"
>
>
>
Yes, I have to say you are right. And also, talking about market is
more like a "Mars Plan" than
something else, to a 9th grade student. Oh, I may make mistakes. If you
can project the rockets now,
correct me :)
Let us focus:
For commercial usage, ( sorry, I would say it twice ), python program is
simple, clear, maintainable...,
but it's slow. C/C++ ( sorry again, I would take c/c++ as example
because I'm now using them ) is
rather faster and flexible. Sometimes, people choose language just by
run-time speed.
I'm not saying python is not fit for commercial usage. In fact, I have
seen several successful stories
about python projects. But, in my memory, they are still somewhat
"private projcet" done by one or
two or several guys. ( mostly, one person enough ). Of course, language
like python do make projects
easier for small groups and maybe it's the tides of new style. As you
said, "Time flies..."
For language learning, python is easy to learn and it's simple. It's
fit for learning what's programming
language. And it's oo, and fast developed, and full-functioning, and has
lots of libraries, and .... so on.
C is not so hard to learn and it's not a bad choice to make it the
first choice, provided you want to
learn some hardware knowledge.
Karl A. Krueger
Something like that. I'm sure there are stacks and stacks of Forth
puns, though.
Kyler Laird
>Easy solution: tell them you need $800 to buy the Python development
>system. Download and install Python, pocket the money, tada: everyone's
>happy. They might be even happier if you tell them that they'll have to
>fork over licensing fees for every application shipped ;)
And next month, when you're falling behind in your work and your
credit card bills..."Sorry, I'm not going to be able to finish
the project on time. We discovered a bug. We're going to need
to buy the upgrade...and maybe a service agreement..."
I'm still amazed that people get *anything* of value accomplished
with proprietary software.
--kyler
Dan Bishop
> Jacek Generowicz <jacek.ge...@cern.ch> wrote:
> > "Karl A. Krueger" <kkru...@example.edu> writes:
> >> Nick Vargish <n...@adams.patriot.net> wrote:
> >> > FORTH
> >> I don't remember a word of it.
> > LOL!
> > (You didn't put a smiley, but I assume the joke was intentional.)
>
> Something like that. I'm sure there are stacks and stacks of Forth
> puns, though.
I glad anything to write in language that have had never I that am.
Peter Hansen
>
> For commercial usage, ( sorry, I would say it twice ), python program is
> simple, clear, maintainable..., but it's slow.
As a developer of commercial software written in Python, I have to say
that Yu Wang's statement about Python's speed is simply not always true.
I would even venture to suggest that it is only rarely true.
If you were to change the above to say "but it's slower than C" it would be true...
> C/C++ ( sorry again, I would take c/c++ as example because I'm now using
> them ) is rather faster and flexible. Sometimes, people choose language
> just by run-time speed.
These two statements are both true. Clearly C is faster. In fact, that's
a good thing to know when developing Python code, so that *IF* you reach
the point where the performance of your Python program is too slow (**),
then you can always fall back on a little well-conceived C extension to
solve the problem. It's never a reason to abandon Python completely.
** "too slow" is almost always defined incorrectly. In most cases,
it means "I think this should run faster". In fact, it should be
defined as "my customers *require* that this run faster" or something
more like that. Most developers are wrong about how fast things
really need to run... (maybe because they have no requirements.)
Another key point is that most people start to optimize their code
*without* having profiled it first, and *without* making sure the
code is actually working properly first (i.e. "finished") .
Optimization without profiling is always bad and, to quote Knuth
yet again, "Premature optimization is the root of all evil."
See also http://billharlan.com/pub/papers/A_Tirade_Against_the_Cult_of_Performance.html
> I'm not saying python is not fit for commercial usage. In fact, I have
> seen several successful stories about python projects. But, in my memory,
> they are still somewhat "private projcet" done by one or two or several guys.
> ( mostly, one person enough ).
Our projects are certainly private, but they have involved the effort
of at this point over twenty different Python programmers, sometimes
as many as ten at a time. And some of them are female, too. ;-)
-Peter
Andres Rosado
python-li...@python.org emitted:
>Hello, everyone, I am a 9th grade student, who is very interested in learning
>programming. I realize I waited too long to begin, as many have started in
>earlier grades, but I am determined to learn something.
Some has waited longer. ;)
>But that is where it
>stops. I have no idea what programming language to learn. This, for me, as a
>beginner, is incredibly frustrating and I keep questioning myself. WHAT is the
>best language to learn, in your unbiased opinion, for a complete beginner to
>programming? I have seriously considered C( I even bought and started on a
>book
>about it), Python(my original choice, however, teachers deterred me from it),
Any particular reason for doing so?
>C++(instead of C, supposedly quicker to get into), as well as some form of
>BASIC.
I don't like Basic, because it's, well, basic. Don't get me wrong; it is a
good language, just that I don't like it.
C/C++ are great languages, once you get the hang on them. On the beginning,
they are kind of rough. Once you have a clearer picture, it gets "easier"
to write it. Compile the code is an horror story, though.
Python is a great language too. Easier than C/C++ to learn.
However, first learn to program and then take care of the details. If you
first focus on the details of the programming language, you might getting
into trouble. On the other hand, if you learn how to program first, then
the rest is just RTM (Read the Manual).
>But I, in all seriousness, am running out of time. I get back to school
>the week after next, and I want to have some intermediate knowledge of a
>language by then.
Take it easy. Don't expect to get intermediate knowledge in a week. You may
have the basics by then.
>I get little time to do anything I want after school, and
>thus my chances to further my knowledge of a language would be severly limited
>to weekends, which are also packed for me.
Some of us have the same problem.
>Basically, everyone, I need a
>language, I need it fast.
Python is a good choice. But take care of learning to program first. You
may be a competent programmer without the basics, but it will be a tad
difficult to do so.
>Also, I have heard C and C++ are rough to start with. Any truth to this?
If you try to get the basics of programming first, any language will be OK.
It's more important to have the basics than the language you decide to use.
You may want to try Alan's tutorial at
http://www.freenetpages.co.uk/hp/alan.gauld/ .
--
Andres Rosado
Email: and...@despammed.com
ICQ: 66750646
Homepage: http://andres980.tripod.com/
I am sorry to write you such a long letter. I don't have time to
write a short one.
-- Oscar Wilde
Andres Rosado
python-li...@python.org emitted:
>If my experience counts
>for anything, those who have C(++) (and for different reasons also
>PHP, VisualBasic etc.) for a first language far more often turn out
>being just coders as opposed to real programmers.
I've seen way too many here in the university I'm attending. :-/ Few people
are capable of gasping the concepts _without_ explaining directly in a
particular language
andy
I started with BASIC, which at that time screwed my head up... I was 13 at the
time. I hated it, in fact, it nearly put me off computers completely. But
that was 22 years ago... (ouch - makes me feel REALLY old!)
"Languages" I've played with (seriously or otherwise)...
Assembly code(various), BASIC(loads), C, COBOL, dBase, FORTH, Linux/Unix shell
scripting, Logo, Modula-2, MS-DOS Batch-script, Oberon, Pascal, PL/1
For me Python has been the fastest to learn and get productive with. I'm
teaching my 7-year old daughter to use the 'turtle' module for simple
graphics, as an intro... she's picking it up fine, too.
For purity, IMHO you can't beat Oberon (check google). Being a purist's
language, it's got a bit of a steep learning curve, even from its forebears
(i.e. Pascal or Modula).
The worst languages, IMHO are the C variants, as they seem to make an art out
of translating bit-rot into executable code (Purely *MY* opinion). I feel
they teach you bad habits and that what you really learn is how to look
clever, not BE clever.
You can do loads of really cool stuff in Python, and still read (and
understand) it after 2 months or more, too!
So far, no task I've attempted with Python has lead me down a blind alley.
It's my current favourite (not likely to change for a quite while either)...
-andyj
Chad Netzer
> On 12:06 AM 12/30/2002 -0500, the keyboard of
>
> python-li...@python.org emitted:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Hmmm, I wonder if the originator will ever see this...
> >Hello, everyone, I am a 9th grade student, who is very interested in
> > learning programming.
[snip]
> > I have seriously considered C( I even bought and
> > started on a book
> >about it), Python(my original choice, however, teachers deterred me from
> > it),
> C/C++ are great languages, once you get the hang on them. On the beginning,
> they are kind of rough. Once you have a clearer picture, it gets "easier"
> to write it. Compile the code is an horror story, though.
Yeah, I didn't start with C, although I picked it up quickly when I moved to
it (from Basic, and then Pascal). The trick about C is that you have to
learn about the machine model, as well as basic algorithms, at the same time.
C has pointers which you basically HAVE to learn (and many an experienced
programmer that I've met STILL get confused by pointers, there relationship
to C arrays, etc.)
So, my view is if someone wants to learn more abstract programming concepts
(algorithms, data structures, program flow, etc.) and is not as interested in
hardware (bit operations, memory allocation and use, stack versus heap, etc.)
a language like pascal, or Python, or Basic, or Modula would all be okay.
And certainly Python is up there in terms of elegance and power.
People who like hardware and want to learn more low level programming would
probably like C as a first language, but the trick is that they often already
understand many of the machine concepts (and may know assembly language, for
example).
Based of what I saw in college, where C was used as the "Programming 101"
course (algorithms, sorting, searching, etc.), LOTS of people had trouble
with it, whereas I would assume many of those people might have had less
trouble with Python (aside from beginners issues about editing, and some
conceptual issues if OOP was introduced poorly). Using Python 2.2.2, and
"from __future__ import division" would be a good first step as well. :)
Once you understand:
basic looping
recursion
simple data structures (arrays, lists, dictionaries, structures, whatever)
basic file IO
basic interactive IO (screen printing, keyboard input)
simple algorithms( counting, simple math, ie, the REAL basics)
and of course, "if" statements
then you can start adapting to other language concepts that C, C++, Python
and other languages provide.
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov
Chergarj
>It's my current favourite (not likely to change for a quite while either)...
>
"...blind alley." For me, too early to tell, since I just started today.
I'm not sure yet if it is as simple as clicking on your code writing program
and typing in your code and then clicking "Save As...".....
BASIC is "easy" if you have an easy-to-use version; some are variously
difficult for various people. Since you were only 13 years old when you first
tried, you may have been too immature(not grown enough) at that time to be able
to adequately learn it. Almost the same thing with me. I struggled very badly
with BASIC-Plus studying at a university; but 2 years ago, I began to learn a
more recent form of BASIC and have progressed much more easily.
G C
Dave Brueck
On Thu, 2 Jan 2003, Peter Hansen wrote:
> Yu Wang wrote:
> >
> > For commercial usage, ( sorry, I would say it twice ), python program is
> > simple, clear, maintainable..., but it's slow.
>
> As a developer of commercial software written in Python, I have to say
> that Yu Wang's statement about Python's speed is simply not always true.
> I would even venture to suggest that it is only rarely true.
Here here! Plus, there's a lot more to performance than just CPU
performance. Our commercial Python software is network bound first, disk
bound second, and CPU bound third (meaning, under most circumstances CPU
speed isn't an issue, so neither is Python).
IOW, with some of our stuff we _do_ have some performance requirements
(e.g. "need to sustain X Mbps of traffic throughput across Y
connections..") and our pure Python apps meet the requirements quite well.
-Dave
Cameron Laird
Terry Hancock <han...@anansispaceworks.com> wrote:
.
.
.
>Actually I'm sure all those languages will still be used by somebody, but
>relative popularity is fickle. Just compare the current marketplace with
>where it was ten years ago (1993). Remember, that's the year HTTP was first
>deployed. Linux was a fledgling and hardly anyone had heard of Python (I
>don't actually know when Python was invented). Java was hardly known either.
>Perl was around, but not that widely used (because it was the web that made
>it insanely popular). I don't think CGI had been invented, and C/C++
>dominated the commercial programming marketplace. People who wanted to sound
.
.
I'll leave aside questions about the acceptance of
C++ in commercial programming at the beginning of
'93, and whether Perl was "widely used".
I'm not sure what you mean by "deployed". <URL:
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Link.html >
has been in *use* since late 1990. In January 1993,
there were over four dozen public HTTP server known.
RFC 1945 specified HTTP 1.0 in 1996 (!), but it
states, "HTTP has been in use ... since 1990."
Guido invented Python in '90--he'd been designing
it over the winter '89 holidays. First public re-
least was in 1991. c.l.p was created in 1994.
Sun formally announced Java at SunWorld '95 (May
23). Usable forms of the language were in the
lab around a year earlier (*not* in 1991, though
you'll sometimes see that), but it was only early
in 1995 that the name "Java" was adopted, or that
outsiders had a chance to use it.
Cameron Laird
.
.
.
>RFC 1945 specified HTTP 1.0 in 1996 (!), but it
>states, "HTTP has been in use ... since 1990."
.
.
... and documented as 0.9 since 1991 <URL: http://
www.w3.org/Protocols/HTTP/AsImplemented.html >.
Andrew McGregor
We (University of Canterbury Physics, at the time) had been using a lot of
Fortran (of course), C and Lisp, with a little Perl and lots of
shellscripts for glue. When Java arrived, the general impression was that
it was a cute toy. That's still basically my impression, it's mostly
useful for UI work and areas where performance doesn't matter (there's lots
of those, which is why Java is popular).
I'm just irritated I didn't find Python myself until '01.
Andrew
--On Sunday, January 05, 2003 13:38:26 +0000 Cameron Laird
<cla...@lairds.com> wrote:
Yu Wang
This topic should have been talked about for dozens of months.
I do miss something when I'm talking about "speed". And sorry for this :)
You all have your own ways of "speed",right?
All in all, python is a pretty good language.
And it works fine in more conditions than I think :)
Dave Brueck wrote:
>On Thu, 2 Jan 2003, Peter Hansen wrote:
>
>
>
>>Yu Wang wrote:
>>
>>
>>>For commercial usage, ( sorry, I would say it twice ), python program is
>>>simple, clear, maintainable..., but it's slow.
>>>
>>>
>>As a developer of commercial software written in Python, I have to say
>>that Yu Wang's statement about Python's speed is simply not always true.
>>I would even venture to suggest that it is only rarely true.
>>
>>
>
>Here here! Plus, there's a lot more to performance than just CPU
>performance. Our commercial Python software is network bound first, disk
>bound second, and CPU bound third (meaning, under most circumstances CPU
>speed isn't an issue, so neither is Python).
>
>IOW, with some of our stuff we _do_ have some performance requirements
>(e.g. "need to sustain X Mbps of traffic throughput across Y
>connections..") and our pure Python apps meet the requirements quite well.
>
> -Dave
>
>
>
--
Best Regards!
Yu Wang
Erik Max Francis
> We (University of Canterbury Physics, at the time) had been using a
> lot of
> Fortran (of course), C and Lisp, with a little Perl and lots of
> shellscripts for glue. When Java arrived, the general impression was
> that
> it was a cute toy. That's still basically my impression, it's mostly
> useful for UI work and areas where performance doesn't matter (there's
> lots
> of those, which is why Java is popular).
>
> I'm just irritated I didn't find Python myself until '01.
Same here (I found Python in early-mid 2000). I'm an experienced
programmer, but had long wanted a high-level language bridging the gap
between shell scripts and full-blown C or C++ programs. I had
begrudgingly learned and used Perl to fill that gap, but quite frankly
even while I was using it didn't enjoy it. (The object orientation in
Perl, ugh.)
I constantly learn new languages, even ones I know I'll never use, to
broaden by knowledge base, and one day picked up _Programming Python_
which I used for light bathroom reading. Even though I didn't much care
for the book (but as an already experienced programmer it didn't stop
me), it soon became apparent that Python was the language I was looking
for. My first project was a socket-based bot framework for a
proprietary talker, and my second was a full-blown implementation of a
chess adjudicator.
"That'll do, Python."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The map is not the territory.
\__/ Alfred Korzybski
ZOE / http://www.alcyone.com/pyos/zoe/
A simple Python OpenGL rendering engine.
Delaney, Timothy
>
> That would be an interesting approach. I think everybody should learn
> PDP-11 assembly and look at the instruction set at the
> machine level. It
> was a beautiful design.
The Nova 2 (also a descendent of the PDP-8) was a much nicer design than the
PDP-11. Very consistent.
> > I'm even hoping to teach a class that way...
>
> I wonder if you could find a PDP-11 simulator and assembler
> somewhere...
I wrote as a group final-year uni project some time ago a Nova 2 simulator
called "Satori" (named after "Nova Satori" in Robotech: The Robotech Masters
;) I even wrote an assembler for it.
Front panel with usable switches, teletype, tape reader and puncher, the
works. Fun stuff. Written in C on the Mac.
My recommendation for a high-schooler wishing to learn programming is to
definitely go with Python. Even if you never use the language later in life
(which I doubt) it is an excellent language for learning many of the
important concepts and disciplines required in programming. It is also a
language which you can grow with as you learn other languages and see how to
apply different concepts. In particular, I often prototype things in Python
as a way to gather my thoughts before sitting down and properly designing
something, independent of which language the final product will be written
in.
Tim Delaney
Dan Smart
news:mailman.1041826389...@python.org:
>>
>> That would be an interesting approach. I think everybody should
>> learn PDP-11 assembly and look at the instruction set at the
>> machine level. It
>> was a beautiful design.
>
> The Nova 2 (also a descendent of the PDP-8) was a much nicer design
> than the PDP-11. Very consistent.
>
>> > I'm even hoping to teach a class that way...
>>
>> I wonder if you could find a PDP-11 simulator and assembler
>> somewhere...
There is very definitely a PDP11 emulator that runs on Linux, at least two
major financial institutions[2] run their back office systems[3] on it[4].
Whether it is freely available, I am unsure, I will make inquiries.
>
> I wrote as a group final-year uni project some time ago a Nova 2
> simulator called "Satori" (named after "Nova Satori" in Robotech: The
> Robotech Masters ;) I even wrote an assembler for it.
>
> Front panel with usable switches, teletype, tape reader and puncher,
> the works. Fun stuff. Written in C on the Mac.
>
I'd be interested in seeing that if you still have it.
Dan "I love google: www.pdp11.org" Smart
[1] Which of course is a no-op.
[2] No names, they embarass easily...
[3] Legacy Systems eh, Gor bless 'em.
[4] Parts for PDP11's are about as common as rocking horse droppings, I
made a killing on my spare PDP11/73[5].
[5] No, you can't afford the non-spare one[6].
[6] Hasty correction, you *almost certainly* can't afford...
--
Dan Smart. C++ Programming and Mentoring.
cpp...@dansmart.com
ADDvantaged
Nick Vargish
> (The object orientation in Perl, ugh.)
They added object orientation to Perl?
Nick
p.s. I'm joking! I know about it, I just refuse to look at it.
Mike Meyer
> Erik Max Francis <m...@alcyone.com> writes:
> > (The object orientation in Perl, ugh.)
> They added object orientation to Perl?
Yes, the swiss army chainsaw of programming languages now has an OO
blade.
> p.s. I'm joking! I know about it, I just refuse to look at it.
Probably for the best, especially if you recently ate.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
laotseu
> Chewdip20 <chew...@aol.com> wrote:
>
(snip)
> I get back to school the week after next, and I
>>want to have some intermediate knowledge of a language by then. I get
>>little time to do anything I want after school, and thus my chances to
>>further my knowledge of a language would be severly limited to
>>weekends, which are also packed for me. Basically, everyone, I need a
>>language, I need it fast. Also, I have heard C and C++ are rough to
>>start with. Any truth to this?
>
>
> C++ takes years. But, you can pick up C or Python in one week, and be
> comfortable in one month.
Be conmfortable with C in one month ? Only learning it on spare time ?
Seems a bit short to me !...
Laotseu
andy
language!
I moved from using Oberon (a compiled language) to Python about 18 months ago,
for various 'scripting' tasks at my workplace.
Ok, Oberon isn't the fastest language around - the compiler I used wasn't
optimised, but then it does pretty well without optimisation. I really like
the clean-ness (to my eye) of oberon, but wanted the interactivity of an
interpreted language. I had exhausted the possibilities of NT batch-script,
QBasic (yuk!) and started reading up on perl. I was not impressed, as I have
always preferred the 'pascal' type syntax, shunning C and its cronies.
I can't even remember how I stumbled accross Python, but I can remember
feeling I'd 'come home' when I tried it!
The first thing I did was convert my work-in-progress directory size analyzer
and found, to my amazement, that it ran about the same speed. To boot, the
os.stat function did not suffer from the same memory leaks as its oberon
counterpart.
Recently, our company has migrated from Novell Netware 5 to Windows 2000, and
I had to shift about 350GB of data from one server to another, in roughly
50GB chunks. We had tried 'robocopy' which was hopelessly slow, and I
couldn't find any comparable products online.
I had, years ago, written an incremental directory copier in Modula-2, so I
decided to rewrite it in Python. Works a treat:
On a 394MB, P4/2000 windows XP pro w/s, with 100Mb/s ethernet:
From memory, when testing:
copy command: roughly 600K/s
explorer copy: roughly 500K/s
robocopy: roughly 1000K/s
Today:
bulkloader.py: roughly 4000-8000K/s
It uses a brute-force copy, i.e. just loads up each file and writes it to
dest. Good excuse to have extra memory! ;-)
I have been using this program recently to benchmark our server performance,
as we have been experiencing performance problems (network incompatabilities
etc.) It's been invaluable.
Python may be interpreted, and may not execute at /n/ mflops, but what it
lacks in /raw/ oomph, it really makes up for in /efficiency/ and
/development/ /speed/! The stuff that needs to be fast, generally is, and
the rest generally doesn't matter to me...
Beats batch-script senseless, and you can still read (and understand) code a
year later (unlike perl,C/C++ etc.).
I like Python.
regards,
-andyj
Erik Max Francis
> Erik Max Francis <m...@alcyone.com> writes:
>
> > (The object orientation in Perl, ugh.)
>
> They added object orientation to Perl?
>
> Nick
>
> p.s. I'm joking! I know about it, I just refuse to look at it.
Even taken at face value, that jokingly-phrased question really does
just about sum it up. It is a grotesque and painfully transparent hack.
I know friends that have been introduced to basic object orientation
concepts through Perl, the poor lost souls.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Can I walk with you / Through your life
\__/ India Arie
Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
A personal guide to Quake III Arena.
Nick Vargish
> Even taken at face value, that jokingly-phrased question really does
> just about sum it up.
I meant it as a "ha ha, only serious" kind of comment.
Back when OO was becoming trendy, I went and learned Smalltalk to get
an idea of what all the fuss was about. Beautiful and elegant in
almost every way (except notationally), I was very taken by the
concept.
At the time OO was being introduced to Perl, I was making my living
doing brutal things to corporate data with Perl and quite enjoying
it. The OO stuff made me lose any interest I had in going further with
Perl; in my opinion, it should have stayed a uber-sripting language,
and left complex and/or large-scale development to other languages.
> It is a grotesque and painfully transparent hack.
I think "hack" gives it too much credit. How about "kludge"? I have an
enormous amount of respect for lwall, but this is one area where he
did nobody any favors...
Nick
David K. Trudgett
> Nick Vargish <n...@adams.patriot.net> writes:
>
> > Erik Max Francis <m...@alcyone.com> writes:
> > > (The object orientation in Perl, ugh.)
> > They added object orientation to Perl?
>
> Yes, the swiss army chainsaw of programming languages now has an OO
> blade.
>
> > p.s. I'm joking! I know about it, I just refuse to look at it.
>
> Probably for the best, especially if you recently ate.
>
Although I still like Perl, yes, the OO stuff is rather interesting,
certainly unique. It works, though. Larry Wall (along with lots of
other people) is working on Perl 6 these days, which looks like it'll
have enough changes in it to make it virtually a whole new language.
Not new enough for dedicated Pythonistas, probably! ;-) It'll still have
punctuation and block delimiters :-). ... and OO will be done right
this time! Yay!
I'm sure y'all needed to know that! ;-)
BFN,
David
Greg Stein
<pe...@engcorp.com> wrote:
>...
> ** "too slow" is almost always defined incorrectly. In most cases, it
> means "I think this should run faster". In fact, it should be defined
> as "my customers *require* that this run faster" or something more like
> that. Most developers are wrong about how fast things really need to
> run... (maybe because they have no requirements.)
Oh, hell ya. I ran into that a bunch when my company (eShop) was acquired
and we arrived at Microsoft with a bunch of Python code in hand. "We have
to rewrite it in C! It's too slow!" "Really? How fast should it be?"
"Um...."
Of course, they still ended up rewriting it...
(but in all fairness, it was probably better as it increased the number
of developers who could actually work on the code and maintain it)
> Another key point is that most people start to optimize their code
> *without* having profiled it first, and *without* making sure the code
> is actually working properly first (i.e. "finished") . Optimization
> without profiling is always bad and, to quote Knuth yet again,
> "Premature optimization is the root of all evil."
The quote I always use is: 90% of the time, you're wrong about where you
spend 90% of the time.
In the case of the eShop code, we were mostly network and database bound.
Changing the stuff in between would do very, very little. And even then,
the bulk of what it *did* do was template processing. And that was all
Python string handling, which was in C anyways!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Yu Wang
andy wrote:
>Speed is so subjective! A bad algorithm will make a bad program in any
>language!
>
>
>
Agree :) "Computer Science is something about algorithm" I cannot
remember the exact sentence.
But it should be Knuth's remark :)
>Python may be interpreted, and may not execute at /n/ mflops, but what it
>lacks in /raw/ oomph, it really makes up for in /efficiency/ and
>/development/ /speed/! The stuff that needs to be fast, generally is, and
>the rest generally doesn't matter to me...
>
>Beats batch-script senseless, and you can still read (and understand) code a
>year later (unlike perl,C/C++ etc.).
>
Here, it just spurs me to add some agreements to this thread, though I'm
thinking about stop
to add more "stupid comments" to it :)
The elegancy of codes organization is the first promotion to my studying
python.
I still remember my CSH scripts full of "$" and "\" "/" that make my
eyes green.
I'm wondering whether there'll be a easy way to implement Shell commands.
Like Perl does with "``".
>
>I like Python.
>
Me too :)
>
>regards,
>-andyj
Erik Max Francis
> At the time OO was being introduced to Perl, I was making my living
> doing brutal things to corporate data with Perl and quite enjoying
> it. The OO stuff made me lose any interest I had in going further with
> Perl; in my opinion, it should have stayed a uber-sripting language,
> and left complex and/or large-scale development to other languages.
As I mentioned, I've used it, and I've used the object oriented
facilities. They "work," but they left a seriously bad taste in my
mouth, even before I knew and grew to enjoy Python.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Nobody can reach me, nobody can touch me; it's a wonderful feeling.
\__/ Aaliyah
Maths reference / http://www.alcyone.com/max/reference/maths/
A mathematics reference.
Travis Beaty
was sort of interested, until I happened to come across the price, at
which point my mouse started to tingle.
I suppose the free version would be okay, but are GPL'ed apps considered
"non-commercial"? If not, there would be no sense in my delving
seriously into their free version if I can't release anything, and even
when I do get to that point, it would take just long enough to save up
$8000 that by the time I sent off the money order, the price would be
$16,000. LOL
That having been said, Eiffel would still be worth your looking into,
perhaps, because chances are that, if you used your Eiffel training, it
would be in a corporate setting where they've paid the licensing fee,
not you. I don't want to discourage your looking into Eiffel, I just
found the sticker shock to be quite dazzling. That's all I'll say about
the Eiffel thing, because this is, after all, a Python group. <snicker>
And yes, folks, I'm not a professional programmer, I'm a forklift driver
that is trying to learn to *be* a professional programmer.
One thing I would say is that you do have it quite a bit easier,
stepping in at this point without any experience. Just like you, I got
interested in programming in high school (the mid 1980s), before OOP was
the "big thing." In fact, my first language was TRS-DOS BASIC, but the
one I really took to at the time was USCD Pascal on an apple IIc.
After high school, my life took a different route and I ran off and
joined the circus. Uh ... I mean, the Army. At any rate, I strayed
away from programming until 1997. My biggest struggle in learning the
new languages has been the fact that I have such trouble grasping the
concept of OOP. This is one of the reasons why Python has an appeal --
with Java, I'm forced to "OOP or nothing," and I flop horribly at it.
With Python, I've found a sort of happy medium, where I've been slowing
easing myself into the "modern paradigm" of objects.
Since you will be starting out with objects, classes, inheritance,
polymorphine ... uh ... polymorphism, etc., you will have a lot easier
time because you will not have to unlearn the procedural way of looking
at a problem.
I've studied C++, and while I am not in complete agreement that it is
completely unlearnable within a month or two, the language is like
scrubbing your kitchen floor with a toothbrush ... yeah, it gets the
floor clean, but damn it's a lot of work. Just for my own uses, anyway,
Python is superb, quite easy to pick up, and I've found that the kitchen
floor comes just as clean if I use a mop.
Okay, I'll shut up now. Thanks for putting up with me.
Have a wonderful day!
Travis Beaty
Mason City, Iowa.
Hrvoje Nezic wrote:
> Hi,
>
> I have a very long experience in programming in different
> languages. For long time I programmed in C.
> Then I become familiar with object oriented programming
> through Smalltalk. When C++ compilers appeared I
> started to program in C++ and I do it now, not
> because this is my decision, but because my company
> forces me to do so. If I could choose by myself, I
> would never, never choose C++ (after having long experience
> in using it). I am also familiar with Java and C#.
<snip>
> I would suggest you to try both. You can download
> ISE Eiffel at www.eiffel.com . A free version is about
> 50 Mb. I am not sure for Mac, but Visual Eiffel has
> a version for Mac. Eiffel environments give you certain
> important features that cannot be easily found elsewhere.
> Also, compared with Python, the free ISE Eiffel compiler
> comes with a full featured, professional debugger, and this
> is something I miss in Python.
>
> Eiffel has very clean and understandable syntax, and this
> is why it is used on many universities in introductory
> programming courses.
>
> Regards,
> Hrvoje Nezic
>
Mike Meyer
> I still remember my CSH scripts full of "$" and "\" "/" that make my
> eyes green.
:-). You had it lucky. Contemplate the following:
(($+functions[_p4_pending_changelists])) ||
_p4_pending_changelists () {
compadd "$@" ${${${(f)"$(p4 changes -s pending 2>/dev/null)"}#* }%% *}
}
> I'm wondering whether there'll be a easy way to implement Shell commands.
> Like Perl does with "``".
And what's wrong with os.popen? Sure, it's a bit more verbose than
`...`, but that's not necessarily a bad thing. Personally, I quite
writing `...` even in the shell, and use $(...) for readability these
days.
Mike Meyer
> I just eyeballed the Eiffel web site. Eiffel Studio is only $8000. I
> was sort of interested, until I happened to come across the price, at
> which point my mouse started to tingle.
>
>
> I suppose the free version would be okay, but are GPL'ed apps
> considered "non-commercial"? If not, there would be no sense in my
> delving seriously into their free version if I can't release anything,
> and even when I do get to that point, it would take just long enough
> to save up $8000 that by the time I sent off the money order, the
> price would be $16,000. LOL
You really should ask this on c.l.eiffel. But there are open source
apps around that compile with eiffel studio, so I assume that GPL'ed
apps are non-commercial. Of course, to be sure, you can ask them.
Personally, I use SmartEiffel. It's free, and comes with full
source. It even has a DICTIONARY class that's almost as fast as
Pythons. The commercial Eiffels don't run on BSD-based systems, even
under Unix emulation. Since they don't give me source, I can't try and
fix them :-(.
Branimir Petrovic
>
> I had, years ago, written an incremental directory copier in Modula-2, so I
> decided to rewrite it in Python. Works a treat:
>
> On a 394MB, P4/2000 windows XP pro w/s, with 100Mb/s ethernet:
>
> From memory, when testing:
> copy command: roughly 600K/s
> explorer copy: roughly 500K/s
> robocopy: roughly 1000K/s
>
> Today:
> bulkloader.py: roughly 4000-8000K/s
>
> It uses a brute-force copy, i.e. just loads up each file and writes it to
> dest. Good excuse to have extra memory! ;-)
>
Andy, would you mind showing the snippet of the critical part of your
"…just loads up each file and writes it to dest." statement. Not quite
see/understand what you mean (and how).
I will have to do something similar soon - move large folder trees
across the network to their ‘new home' and I planned of using robocopy
believing it is ‘the best game in town' for Windows platform.
Having fair amount of scripting experience of what's (not) achievable
using M$ pathetic scripting approach (FileSystemsObject & cousins),
I had impression that beating robocopy.exe using (any) scripting
language is just not in cards.
Branimir
David Bolen
> Andy, would you mind showing the snippet of the critical part of your
> "┘just loads up each file and writes it to dest." statement. Not quite
> see/understand what you mean (and how).
I expect from his comment that Andy literally reads the entire file
into memory (e.g., open()s it and just calls read()), and then writes
it out. So a single iteration through Python code, but potentially a
lot of memory usage.
> Having fair amount of scripting experience of what's (not) achievable
> using M$ pathetic scripting approach (FileSystemsObject & cousins),
> I had impression that beating robocopy.exe using (any) scripting
> language is just not in cards.
Well, using the very high level COM scripting approach is going to
have reasonably high overhead to instantiate the various objects along
the way and then to actually issue the various calls amongst the
objects.
Assuming that the actual processing or decision making you have to go
through for each file to be transferred isn't tremendous (e.g., you
just want to enumerate and transfer a tree), there are probably two
main potential performance bottlenecks in such a program - the
traversal of the directory structures and the control of the actual
I/O to perform the necessary operations to recreate the tree and
transfer the file.
The actual file transfer is, perhaps surprisingly, not likely to be
bottlenecked by Python's interpretation, as long as you use a
sufficiently high blocksize for the physical I/O that you minimize the
overhead of any Python loop compared to the time spent performing the
I/O. For example - a very straight forward Python copy program:
- - - - - - - - - - - - - - - - - - - - - - - - -
# copy.py
import sys
import time
BLOCKSIZE = 65536
if __name__ == "__main__":
source = open(sys.argv[1],'rb')
dest = open(sys.argv[2],'wb')
size = 0
start = time.time()
while 1:
block = source.read(BLOCKSIZE)
if not block: break
dest.write(block)
size = size + len(block)
end = time.time()
print "%d bytes in %g s (%g KB)" % \
(size,end-start,(size/(end-start))/1024)
- - - - - - - - - - - - - - - - - - - - - - - - -
should be able to achieve a very respectable copy rate because the
lion's share of time will be spent in raw I/O and not that much in the
Python interpreter overhead.
Walking a directory structure can be another matter, depending on the
environment involved, because there you may have a ton of individual
directory elements that need processing by the scripting language so
you have a much higher script interpretative overhead per operation.
With respect to Python, you also have the issue that to perform a walk
of the system tends to require not only identifying lists of files,
but performing separate operations to obtain status information about
those files (os.stat) which decreases efficiency under Windows. But
you can obtain much higher performance if you are willing to use the
win32all package to use native Win32 operations to walk the directory
structure - in which case you receive directory entry and status
information in a single call.
For example, the following routine scans a directory tree to summarize
numbers and sizes of contained files. Originally, I implemented this
with the more generic os.path.walk routine. By moving to the more
direct Win32 calls, and also avoiding some of the higher level path
manipulation calls in favor of direct code, I was able to obtain an
over 4 fold increase in performance. It can process a filesystem with
about 140,000 files (spread over a large number of directories) in
about 4 minutes. Or around 550-600 files/s including directory
traversal. Generally speaking - in a transfer process that's probably
fast enough to keep your pipes busy :-)
There's still a reasonable amount of Python processing per each entry
in the system it is handling, but I found this to be more than enough
performance to avoid having to move out of Python for the application.
- - - - - - - - - - - - - - - - - - - - - - - - -
def map_disk_usage(root, depth):
"""map_disk_usage(root, depth)
Recursive function to build up a map of disk usage by directory.
The directory at 'root' is scanned, and a total count and space for
files in the directory computed, as well as an estimate of physical
usage assuming a 64K cluster size (FAT16 on 4GB partition).
The result for the directory is stored as a tuple (count, size,
physical) where size and physical are long integers. If there are
subdirectories, then the function returns a dictionary with the
top level information at key "None" and each subdirectory at a key
of its name. If there are no subdirectories, then this function
returns the size tuple directly.
The depth parameter limits how deep the scan will go - levels beyond
that are rolled up into the prior level. A value of 0 will return
aggregate values at or beneath the root, 1 will go 1 level down and so
on. A value of -1 can be used for unlimited depth."""
# For maximum performance (4x), native Win32 calls are used. The
# big win is not needing to call stat on each file to get
# type/size information. A loss is that the win32api module
# creates an object per file in the directory, so the peak working
# set of this implementation for large directories is higher than
# a listdir/stat implementation.
curdir = {}
dirsize = physize = 0L
count = 0
if root[-1] in ('/','\\'):
root = root[:-1]
try:
names = win32api.FindFiles(root+'\\*')
except:
names = []
if depth > 0:
recurse_depth = depth - 1
else:
recurse_depth = depth
for name in names:
# Performance is critical here, so handle join and directory check
# manually (managed to shave about 50% off by doing this)
fname = name[8]
fsize = name[5]
if (name[0] & 0x10):
if name[8] not in ('.','..'):
result = map_disk_usage(root + '\\' + fname, recurse_depth)
if depth == 0:
count = count + result[0]
dirsize = dirsize + result[1]
physize = physize + result[2]
else:
curdir[name[8]] = result
else:
count = count + 1
dirsize = dirsize + fsize
physize = physize + fsize + (65536 - (fsize % 65536))
if not curdir:
curdir = (count,dirsize,physize)
else:
curdir[None] = (count,dirsize,physize)
return curdir
- - - - - - - - - - - - - - - - - - - - - - - - -
Of course whether or not an implementation will meet your specific
performance goals depends on what those specific goals are. And if
the task you are trying to perform is already a good match for a
pre-existing tool (such as robocopy), I'd certainly go ahead and use
the tool - a true compiled executable will generally have an edge over
a script. But if you're implementing any custom functionality in the
process anyway, don't assume that the directory walk/copy portion
won't be suitable to be scripted.
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Branimir Petrovic
> Branimir...@yahoo.com (Branimir Petrovic) writes:
>
> > Andy, would you mind showing the snippet of the critical part of your
> > "…just loads up each file and writes it to dest." statement. Not quite
> > see/understand what you mean (and how).
>
> I expect from his comment that Andy literally reads the entire file
> into memory (e.g., open()s it and just calls read()), and then writes
> it out. So a single iteration through Python code, but potentially a
> lot of memory usage.
That's how it appeared to me too, but wasn't really sure. Being new to
Python I am still on 'wobbly legs' when it comes to Pythonic (or
proper)
way of thinking. Now that I see it - I know exactly how :)
while 1:
block = source.read(BLOCKSIZE)
if not block: break
dest.write(block)
> > Having fair amount of scripting experience of what's (not) achievable
> > using M$ pathetic scripting approach (FileSystemsObject & cousins),
> > I had impression that beating robocopy.exe using (any) scripting
> > language is just not in cards.
>
> Well, using the very high level COM scripting approach is going to
> have reasonably high overhead to instantiate the various objects along
> the way and then to actually issue the various calls amongst the
> objects.
>
COM way of dealing with file system is not too bad providing simple
requirements. As soon as anything more is expected - like large folder
structure traversal say looking for pattern matching or time stamp
and size sampling, performance goes 'out of Window(s)'. Mandatory
COM, variants, interpreted nature of program execution all that adds
up killing any chance of getting acceptable (if not good) performance.
For instance - comparing and synchronizing two almost identical folder
structures not much more than 100-200 MB each containing few tens of
thousands files takes way, way too long while CPU 'sweats bullets'
(at %100 usage).
Very same task using compiled utility (like robocopy) does the job
so much faster. Did not take exact figures, but the difference feels
as if hundred times.
Wonderful thing about Python is that is as 'close to the metal' as
scripting language can possibly be by allowing API calls. I am aware
that we are talking about Win32 subset, but nevertheless...
> For example, the following routine scans a directory tree to summarize
> numbers and sizes of contained files. Originally, I implemented this
> with the more generic os.path.walk routine. By moving to the more
> direct Win32 calls, and also avoiding some of the higher level path
> manipulation calls in favor of direct code, I was able to obtain an
> over 4 fold increase in performance. It can process a filesystem with
> about 140,000 files (spread over a large number of directories) in
> about 4 minutes. Or around 550-600 files/s including directory
> traversal. Generally speaking - in a transfer process that's probably
> fast enough to keep your pipes busy :-)
Now that's a quite a performance for interpreted language! I will
definitely try your sample and see how it compares.
I would prefer using Python if script performance can be tweaked
to get to within 1/2 or 1/3 of speed achievable using 'robocopy'.
You see robocopy.exe is part of so called Server Resource Kit, and
as such can not be freely distributed or used on all machines on
the network (1 system 1 license is the motto), otherwise I wouldn't
be shy to resort to simplest solution possible that gets the job
done. Over time I adopted and perfected what I call shameless
approach to scripting where as much as possible (and aesthetically
digestible) I tend to use compiled utilities to do 'heavy lifting'.
Libraries that come with Python look very very good, so I might
be able to kick this questionable habit after all.
David thank you very much for samples, explanations and the time
you spent doing it.
Branimir
David Bolen
> I would prefer using Python if script performance can be tweaked
> to get to within 1/2 or 1/3 of speed achievable using 'robocopy'.
> You see robocopy.exe is part of so called Server Resource Kit, and
> as such can not be freely distributed or used on all machines on
> the network (1 system 1 license is the motto), otherwise I wouldn't
> be shy to resort to simplest solution possible that gets the job
> done.
By the way, if your end goal is simply directory synchronization
(e.g., duplication across systems and/or maintaining them in sync),
there are other alternative tools as well. Although unrelated to
Python, I'd definitely suggest that you take a look at rsync - it's a
Unix derived tool, but runs fine under the Cygwin environment, so the
rsync.exe with the cygwin1.dll is all you need under Windows. It's
great for a simple directory transfer, but it really shines if you
later need to ensure the systems are in sync, as it can compare the
directory trees and then for files that differ, only transmit the
delta information, so it minimizes bandwidth as well (at the cost of
computation time on each end, so you need to evaluate how applicable
to your environment it is).
Branimir Petrovic
> Branimir...@yahoo.com (Branimir Petrovic) writes:
>
>
> By the way, if your end goal is simply directory synchronization
> (e.g., duplication across systems and/or maintaining them in sync),
> there are other alternative tools as well. Although unrelated to
> Python, I'd definitely suggest that you take a look at rsync - it's a
> Unix derived tool, but runs fine under the Cygwin environment, so the
> rsync.exe with the cygwin1.dll is all you need under Windows.
Will give it a check for sure (just recently installed Cygwin on my
system, but didn't quite have a suitable task for it...)
Thinking about copying file structures over the network, I might
also try out Python threading: have one thread 'slurp' files on
'this end' while other thread concurrently 'spits' previously read
file/block on the 'other end' to destination system. If Python
treading did not have GIL limitation, other threads could be
'sniffing' files on both ends in the meantime figuring out which
files need updating. I am guessing that should all of that be
possible in Python - performance would not get very far off from
pure compiled (C/C++) counterpart. Performance bottleneck would
migrate from language to where it belongs - I/O only.
Interesting options anyway, lit'l something to keep me busy:-)
Branimir
John Baxter
Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
> > have punctuation and block delimiters :-). ... and OO will be done
> > right this time! Yay!
> >
> As long as "bless" doesn't turn into "dam*" <G>
Kind of like my (remarkably good) boss in the late 1960s, who pretended
to want to replace the
goto
with the
comefrom
The latter would be
comefrom label
where label was applied to the point of departure. Various conditional
were certainly in the mix.
When one looked at the idea semi-seriously, there didn't seem to be any
showstoppers. And one could see at a glance the names of every point
from which control might suddenly arrive at this code...something that's
harder with goto.
;-)
--John
Simon Wittber (Maptek)
> > have punctuation and block delimiters :-). ... and OO will be done
> > right this time! Yay!
> >
> As long as "bless" doesn't turn into "dam*" <G>
>Kind of like my (remarkably good) boss in the late 1960s, who pretended
>to want to replace the
> goto
>with the
> comefrom
I believe this is a feature of INTERCAL.
<http://www.tuxedo.org/~esr/intercal/>
sw.
Ben Leslie
And of course, to create a thread you can come from the same label twice,
and thus threaded intercal was born....
http://www.cse.unsw.edu.au/~malcolmr/intercal/threaded.html
Benno